On Aug 6, 15:57, I wrote:
>On Aug 4, 20:06, Daniel Stenberg wrote:
>>Hi (Tor)
>>
>>Seeing that all AIX autobuilds with ares currently fail, I'm a bit concerned
>>if there's anything I can do to improve the situation.
[...]

>It coredumps actually (also with --disable-debug):
>gdb> where
>#0 0xd58e5e3c in ares_version ()
>#1 0xd58e5c60 in curl_version_info (stamp=CURLVERSION_THIRD) at version.c:246
>#2 0x100004b0 in operate (config=0x2ff227c8, argc=1, argv=0x2ff22978)
> at main.c:2762
>#3 0x10000388 in main (argc=1, argv=0x2ff22978) at main.c:3587
>#4 0x100001dc in __start ()
[...]

I didn't have time until now to look further at this, unfortunately.
It turned out to be a tricky one and I haven't found a fix yet.

1. Curl coredumps as above on AIX if compiled with --enable-ares
2. It does not coredump if also compiled with --disable-shared
3. In practice, only libcurl has to be a static library for the
   problem to go away, libcares can be shared with no problems.
4. What seems to happen is that when linking in libcurl as a
   shared library, the function ares_version (for all I know it
   could be all ares functions, but that's probably the first one
   touched) is messed up somehow, in the linker table or whatever.
   At least it's not possible to breakpoint at it anymore, and
   while single-stepping through gdb it segfaults as soon as it
   calls ares_version() -- it never actually executes any code in
   the function itself.

I've never seen anything like this on any architecture before, so
if anyone has any ideas I would like to hear them.
The next time I get time to look at this I'll probably go through
my old logs (I keep all the autobuild logs I forward) to see when
the problem stared, and what changes were done between those two
days -- unless someone comes up with some insight or idea.

For now, the only way to have a fully functional curl w/ares
support is to always use --disable-shared with --enable-ares.
(I'm adding one such combo to my autobuilds for now)

-Tor
Received on 2004-09-15