[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: zxid segmentation fault



On Mon, Jan 25, 2010 at 8:34 AM, John Mitchell <jpmitchell@xxxxxxxxxx> wrote:
> Sampo,
>
> On Mon, Jan 25, 2010 at 8:26 AM,  <sampo@xxxxxxxxxxx> wrote:
>> John Mitchell wrote:
>>> All,
>>>
>>>     I have compiled 0.47 and 0.48 of zxid and I am getting a segmentation
>>> fault.
>>>
>>> [jpmitchell@dauntless zxid-0.48]$ ./zxid
>>> Content-Type: text/html
>>>
>>> <title>ZXID SP SSO</title><body bgcolor="#330033" text="#ffaaff"
>>> link="#ffddff" vlink="#aa44aa" alink="#ffffff"><font
>>> face=sans><h1>ZXID SP Federated SSO (user NOT logged in, no
>>> session)</h1><pre>
>>> </pre><form method=post action="zxid?o=P"><h3>Login Using New IdP</h3>
>>> <i>A new IdP is one whose metadata we do not have yet. We need to know
>>> the Entity ID in order to fetch the metadata using the well known
>>> location method. You will need to ask the adminstrator of the IdP to
>>> tell you what the EntityID is.</i>
>>> <p>IdP EntityID URL <input name=e size=100><input type=submit name=l1
>>> value=" Login (SAML20:Artifact) ">
>>> <input type=submit name=l2 value=" Login (SAML20:POST) "><br>
>>> Segmentation fault (core dumped)
>>>
>>> I ran gdb to see what was up:
>>>
>>> Core was generated by `./zxid'.
>>> Program terminated with signal 11, Segmentation fault.
>>> [New process 23890]
>>> #0  0x08064adf in zxid_get_ent_by_sha1_name (cf=0x8f8b520,
>>>     sha1_name=0x8f9d47f "s36Te-rgbzReSjVc8vDDGy89tT8") at zxidmeta.c:302
>>> 302     for (ent = cf->cot; ent; ent = ent->n)  /* Check in-memory cache. */
>>>
>>
>> In gdb, please print cf->cot. I bet it is null.
>>
>> Now, why would that be? Most likely you have empty /var/zxid/cot
>> directory. This situation should obviously be checked by the
>> code as empty CoT is a normal situation in new install.
>> You may be able to work around the situation by using zxcot tool
>> to add at least one partner metadata.
>>
>> I'll add the check to next release. Let me know if the workaround
>> works.
>>
>> Cheers,
>> --Sampo
>>
>> P.S. zxid.c is not exactly the recommended API so you may want to
>> look at zxidhlo.c instead.
>>
>
>   Thanks for the quick response. I tried zxidhlo as you suggested and
> it seg faulted too.
>
>
> [jpmitchell@dauntless zxid-0.48]$ ./zxidhlo
> =================== Running zxidhlo ===================
> t zxidsimp.c:1249 zxid_simple_cf_ses    zx d QUERY_STRING(o=e) 0.48
> t zxidsimp.c:1179 zxid_simple_no_ses_cf         zx d unknown op(e)
> t zxidsimp.c:741 zxid_simple_show_idp_sel       zx d cf=0xbfedb054 cgi=0xbfedaefc
> t zxidmeta.c:701 zxid_my_entity_id      zx d my_entity_id
> url(https://sp1.zxidsp.org:8443/zxidhlo)
> t zxidsimp.c:453 zxid_idp_select_zxstr_cf_cgi   zx d HERE 0x90e52b8 e() m() d()
> Segmentation fault (core dumped)
>
> Core was generated by `./zxidhlo'.
> Program terminated with signal 11, Segmentation fault.
> [New process 24012]
> #0  0x0050fdd0 in __find_specmb () from /lib/libc.so.6
> (gdb) u
> The program is not running.
> (gdb) run
> Starting program: /home/jpmitchell/Source/zxid-0.48/zxidhlo
> [Thread debugging using libthread_db enabled]
> =================== Running zxidhlo ===================
> t zxidsimp.c:1249 zxid_simple_cf_ses    zx d QUERY_STRING(o=e) 0.48
> t zxidsimp.c:1179 zxid_simple_no_ses_cf         zx d unknown op(e)
> t zxidsimp.c:741 zxid_simple_show_idp_sel       zx d cf=0xbfa687b4 cgi=0xbfa6865c
> t zxidmeta.c:701 zxid_my_entity_id      zx d my_entity_id
> url(https://sp1.zxidsp.org:8443/zxidhlo)
> t zxidsimp.c:453 zxid_idp_select_zxstr_cf_cgi   zx d HERE 0x9a3d2b8 e() m() d()
> [New Thread 0xb7f5f8e0 (LWP 24017)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0050fdd0 in __find_specmb () from /lib/libc.so.6
> (gdb) up
> #1  0x004f4c5f in vfprintf () from /lib/libc.so.6
> (gdb) up
> #2  0x004f9e22 in buffered_vfprintf () from /lib/libc.so.6
> (gdb) up
> #3  0x004f4e6f in vfprintf () from /lib/libc.so.6
> (gdb) up
> #4  0x004fee42 in fprintf () from /lib/libc.so.6
> (gdb) up
> #5  0x0806d9d8 in zxid_get_ent_by_sha1_name (cf=0xbfa687b4,
>    sha1_name=0x9a3d30f "s36Te-rgbzReSjVc8vDDGy89tT8") at zxidmeta.c:304
> 304         fprintf(stderr, ent->sha1_name);
> (gdb)
>
>   Hrm. What do you think now?

    BTW. As an interesting experiment I compiled on a Ubuntu box
(totally different platform, compiler, etc), and it works fine. I
figure we might ignore this point for now but it is important from a
support stand point.

>
>>> Seems like an odd place for it to die. This is running on RHEL 5.4
>>> with kernel 2.6.18-164.9.1.el5. The libraries and what not where
>>> compiled with gcc version 4.1.2 20080704 (Red Hat 4.1.2-46). Is there
>>> any known compatibility problems out there or bugs that I should be
>>> aware of?
>>>
>>> --
>>> John P. Mitchell <jpmitchell@xxxxxxxxxx>
>>> 907.450.8320
>>> http://www.alaska.edu/oit/iam
>>
>>
>
>
>
> --
> John P. Mitchell <jpmitchell@xxxxxxxxxx>
> 907.450.8320
> http://www.alaska.edu/oit/iam
>



-- 
John P. Mitchell <jpmitchell@xxxxxxxxxx>
907.450.8320
http://www.alaska.edu/oit/iam