[Namazu-users-en] Re: some queries failing (cgi)

Chad Leigh -- Shire.Net LLC chad at shire.net
Sat Jun 18 09:45:56 JST 2005


On Jun 17, 2005, at 4:11 PM, Chad Leigh -- Shire.Net LLC wrote:

>
> On Jun 17, 2005, at 2:49 PM, Earl Hood wrote:
>
>
>> On June 17, 2005 at 13:05, "Chad Leigh -- Shire.Net LLC" wrote:
>>
>>
>>
>>> So we see it does not get past the tmp=strdup(str); line when str =
>>> chad  . It seems to die in strdup as the cgi_output file ends
>>> abruptly and we do not get any fprintf() from after the call
>>>
>>>
>>
>> Could be memory allocation problem, or memory corruption.  Did
>> you get a core file?  Probably not because your coredumpsize limit
>> is probably 0.
>>
>> Try running things under a debugger.
>>
>> If you do not want to step through Apache code, you could modify
>> namazu.cgi to include a sleep call.  This way you have time to
>> attach to the process with the debugger.
>>
>
> ok, except for when wrapped in fancy GUIs like in Apple's XCode, I am
> a gdb neophyte
>
> I set a break on nmz_codeconv_external which is where the error is
> occuring
>
> Breakpoint 2, nmz_codeconv_external (str=0xbffff620 "chad") at
> codeconv.c:457
> 457     fprintf(stdout,"5       1 -- @%s@\n", str);fflush(stdout);
> (gdb) n
> 454     nmz_codeconv_external (const char *str) {
> (gdb) n
> 457     fprintf(stdout,"5       1 -- @%s@\n", str);fflush(stdout);
> (gdb) n
> 459         tmp = strdup(str);
> (gdb) s
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x400d26e5 in mallopt () from /lib/libc.so.6
> (gdb)

OK, I took the definition of strdup from glibc source and added the  
function directly into my codeconv.c so that strdup() would be my  
version and not the glibc version

I step through it when the query is chad

---
Breakpoint 1, nmz_codeconv_external (str=0xbffff620 "chad") at  
codeconv.c:472
472     fprintf(stdout,"5       1 -- @%s@\n", str);fflush(stdout);
(gdb) n
469     nmz_codeconv_external (const char *str) {
(gdb) n
472     fprintf(stdout,"5       1 -- @%s@\n", str);fflush(stdout);
(gdb) n
474         tmp = strdup(str);
(gdb) s
strdup (s=0xbffff620 "chad") at codeconv.c:94
94        size_t len = strlen (s) + 1;
(gdb) n
95        void *new = malloc (len);
(gdb) p len
$1 = 5
(gdb) p new
$2 = (void *) 0x4
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x400d26e5 in mallopt () from /lib/libc.so.6
---

and when it is paul -- both 4 letter strings that should malloc  
exactly the same.

---
Breakpoint 1, nmz_codeconv_external (
     str=0x8061498 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN 
\"\n        \"http://www.w3.org/TR/html4/strict.dtd\">\n<html>\n<head> 
\n<!-- LINK-REV-MADE -->\n<link rev=made href= 
\"mailto:webmaster at utah.object.com\">\n<!-- LIN"...)
     at codeconv.c:472
472     fprintf(stdout,"5       1 -- @%s@\n", str);fflush(stdout);
(gdb) c
Continuing.

Breakpoint 1, nmz_codeconv_external (str=0xbffff620 "paul") at  
codeconv.c:472
472     fprintf(stdout,"5       1 -- @%s@\n", str);fflush(stdout);
(gdb) n
469     nmz_codeconv_external (const char *str) {
(gdb) n
472     fprintf(stdout,"5       1 -- @%s@\n", str);fflush(stdout);
(gdb) n
474         tmp = strdup(str);
(gdb) s
strdup (s=0xbffff620 "paul") at codeconv.c:94
94        size_t len = strlen (s) + 1;
(gdb) n
95        void *new = malloc (len);
(gdb) p len
$1 = 5
(gdb) n
97        if (new == NULL)
(gdb) p new
$2 = (void *) 0x805f038
(gdb)
----

The malloc(5) fails every time the query is chad but never fails when  
it is paul.  It is exactly the same call and if a resource was being  
exhausted malloc would return an error, and not segv.  malloc()  
should behave the same in both cases since it is the same call ==  
malloc(5)

unless the malloc memory maps were previously corrupted by namazu or  
some other code...

Still investigating

thanks
best
Chad

>
> It always happens in the same place when str = chad but not when it
> is paul or chad* or other things.  This is mighty suspicious to me.
>
> I guess it is off to find the source for glibc (as this is a gentoo
> system) and look at strdup
>
> no other system or program on this machine is having problems
> including much more resource intensive cgi (assumed) under the same
> username so  I think namazu is screwing up the malloc/mallopt maps or
> something
>
> We'll see I guess
>
> Chad
>
>
>
>>
>> --ewh
>> _______________________________________________
>> Namazu-users-en mailing list
>> Namazu-users-en at namazu.org
>> http://www.namazu.org/cgi-bin/mailman/listinfo/namazu-users-en
>>
>>
>
> ---
> Chad Leigh -- Shire.Net LLC
> Your Web App and Email hosting provider
> chad at shire.net
>
>
> _______________________________________________
> Namazu-users-en mailing list
> Namazu-users-en at namazu.org
> http://www.namazu.org/cgi-bin/mailman/listinfo/namazu-users-en
>

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net




More information about the Namazu-users-en mailing list