Daniel Stenberg wrote:
> On Thu, 4 Sep 2008, Jon Drukman wrote:
>
>> I'm not much of a gdb expert but I did manage to trigger a segfault
>> and get a backtrace. Does this tell you anything useful?
>
> You seem to have built parts of this with optimize options (like -O2)
> which does ruin some of the ability to see all details.
>
>> 0x0000003977c61cda in fwrite () from /lib64/libc.so.6
>> (gdb) bt
>> #0 0x0000003977c61cda in fwrite () from /lib64/libc.so.6
>> #1 0x00002b98d031d6d4 in showit (data=0x12661680, type=<value
>> optimized out>,
>> ptr=0x7fffe0311330 "About to connect() to gdata.youtube.com port 80
>> (#0)\n", size=53) at sendf.c:679
>> #2 0x00002b98d031d766 in Curl_debug (data=0x12661680,
>> type=CURLINFO_TEXT,
>> ptr=0x7fffe0311330 "About to connect() to gdata.youtube.com port 80
>> (#0)\n", size=53, conn=0x2b98cb025c50)
>> at sendf.c:726
>
> So this is the DEBUGFUNCTION option in libcurl that somehow crashes when
> it calles fwrite().
>
> I would guess on some sort of memory corruption.
>

i figured it out.

the problem was i was doing something like this in php

$fp = fopen('/tmp/curl.log', 'w');
curl_setopt($ch, CURLOPT_STDERR, $fp);

then passing $ch to another function. it works fine on some setups (mac
os, centos 4) but for whatever reason, it causes segfaults on redhat
(which is weird since i tried RHEL4 and RHEL5, and RHEL4 is supposed to
be the same as centos 4).
the problem is one of these fwrite's in lib/sendf.c (around line 679):

  case CURLINFO_HEADER_IN:
     fwrite(s_infotype[type], 2, 1, data->set.err);
     fwrite(ptr, size, 1, data->set.err);

i think it's the first one. it should probably check to make sure it's
got a valid filehandle before trying to write.

-jsd-

_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-php
Received on 2008-09-18