I have the same problem as Harri, with bzflag-2.0.6 and bzflag-2.0.8
(handbuilt and packaged versions) on Debian unstable / IA32.
With libcurl3, GDB gives the same as above (curl_getdate () and so on).
Using "LD_LIBRARY_PATH=/usr/lib/debug/ gdb bzflag <pid>" (attaching to a
running BZFlag process, with libcurl-gnutls.so.3.0.0 and
libcurl.so.3.0.0 present in /usr/lib/debug/usr/lib/) I'd get this, though:
#0 0xa788d2bb in Curl_splay (i=1151751784, t=0x3f1d70a3)
at ../../../lib/splay.c:68
#1 0xa788d420 in Curl_splaygetbest (i=1151751784, t=0x89c2ec0,
removed=0xafcfc4b4) at ../../../lib/splay.c:205
#2 0xa7887164 in curl_multi_perform (multi_handle=0x894cde0,
running_handles=0xafcfc508) at ../../../lib/multi.c:916
#3 0x0820f631 in cURLManager::perform () at cURLManager.cxx:291
#4 0x081554e9 in playingLoop () at playing.cxx:6099
#5 0x08157a51 in startPlaying (_display=0x8285a60, [EMAIL PROTECTED])
at playing.cxx:6735
#6 0x0812d9e6 in main (argc=1, argv=0xafcfdf54) at bzflag.cxx:1286
As Harri points out, the error appear to occur at an initialisation phase:
The pointer that is sent to Curl_splay (t=0x89c2ec0) is OK, but after
some iterations in the tree an invalid node triggers the bug (with some
or all of the pointers "larger", "smaller" and "same" pointing to
unallocated memory locations, such as "0x3f1d70a3" as seen in frame 0):
(gdb) x/10x 3f1d70a3
0x3f1d70a3: Cannot access memory at address 0x3f1d70a3
(gdb) x/10x 0x89c2ec0
0x89c2ec0: 0x412f0000 0x3f1d70a3 0x41340000 0x3f1d70a3
0x89c2ed0: 0x41390000 0x3f1d70a3 0x413e0000 0x3f1d70a3
0x89c2ee0: 0x41430000 0x3f1d70a3
For quick reference:
struct Curl_tree {
struct Curl_tree *smaller; /* smaller node */
struct Curl_tree *larger; /* larger node */
struct Curl_tree *same; /* points to a node with identical key */
int key; /* the "sort" key */
void *payload; /* data the splay code doesn't care about */
};
/David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
