[JDEV] icqv7 core dumps on external part ?

[David Waite]

Without looking at the code, I can say there is a 99% chance this means 
that there has been memory corruption. Several things could have caused 
this corruption (array write out of bounds, double free, etc.) There is 
a good chance it could be gcc 3.0.1 - there are a ton of changes which 
happened to their C++ implementation between 2.95.3 and 3.0.x. There 
have also been a lot of improvements since 3.0, so if you can upgrade to 
3.0.4, I would recommend it. The STL implementation within versions of 
gcc before 3.0.x were thread-unsafe, especially for std:string (they 
were interally reference-counted, but the reference modification was not 
atomic, nor was the reference comparison)

-David Waite

Wim Godden wrote:

>This is the result :
>
>Core was generated by `icqv7ext'.
>Program terminated with signal 11, Segmentation fault.
>Reading symbols from /usr/local/lib/libsigc-1.0.so.0...done.
>Reading symbols from /lib/libpthread.so.0...done.
>Reading symbols from /lib/libresolv.so.2...done.
>Reading symbols from /usr/local/lib/libstdc++.so.3...done.
>Reading symbols from /lib/libm.so.6...done.
>Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
>Reading symbols from /lib/libc.so.6...done.
>Reading symbols from /lib/ld-linux.so.2...done.
>#0  0x40126e88 in chunk_alloc (ar_ptr=0x401bbd40, nb=16) at malloc.c:2875
>2875    malloc.c: No such file or directory.
>(gdb) bt
>#0  0x40126e88 in chunk_alloc (ar_ptr=0x401bbd40, nb=16) at malloc.c:2875
>#1  0x401265ae in __libc_malloc (bytes=12) at malloc.c:2696
>#2  0x80de950 in _ZNSt23__malloc_alloc_templateILi0EE8allocateEj (__n=12) at
>/usr/local/include/g++-v3/bits/stl_alloc.h:114
>#3  0x806f6d1 in
>_ZN7bedrock3net6SocketC1ERNS0_13SocketWatcherERNS_10ThreadPoolEiiPNS0_5KarmaEPNS0_15ConnectionLimitE
>(
>    this=0x8153010, watcher=@0xbffff81c, pool=@0xbffff7c4, key=0,
>socketfd=-1, karma=0x0, conn_limit=0x0)
>    at /usr/local/include/g++-v3/bits/stl_alloc.h:184
>#4  0x806e655 in
>_ZN7bedrock3net13SocketWatcher19createConnectSocketEPNS0_19SocketEventListenerEPKcS5_iiPNS0_5KarmaE
>(
>    this=0xbffff81c, listener=0xbffff9f4, host=0x814fad4 "127.0.0.1",
>service=0x814fab4 "_jabber._tcp", defaultport=7000,
>    thread_key=0, karma=0x0) at SocketWatcher.cpp:195
>#5  0x80db48e in
>_ZN3jax16RouterConnectionINS_6PacketES1_E7connectERKSsS4_RN7bedrock3net7AddressE
>(this=0xbffff9f0,
>    name=@0xbffff7a4, secret=@0xbffffac0, a=@0xbffff5d0) at
>/usr/local/include/g++-v3/bits/basic_string.h:396
>#6  0x8059516 in _ZN8IcqTransC1ERKSsS1_S1_jb (this=0xbffff7a0,
>serviceid=@0xbffffad0, password=@0xbffffac0, hostname=@0xbffffab0,
>    port=7000, outgoing_dir=true) at IcqTrans.cpp:67
>#7  0x8069c17 in main (argc=1, argv=0xbffffb44) at main.cpp:113
>Current language:  auto; currently c
>
>
>David Waite wrote:
>
>>Wim Godden wrote:
>>
>>>Trying to run it like this :
>>>icqv7ext -n icqv7ext -s secretpass -h 127.0.0.1 -p 7000 -m
>>>sms.localnetwork.local
>>>
>>>I get :
>>>Starting component...
>>>       Component ID : icqv7ext
>>>       Secret       : secretpass
>>>       Jabberd IP   : 127.0.0.1
>>>       Jabberd Port : 7000
>>>Segmentation fault (core dumped)
>>>
>>>
>>>Any ideas ?
>>>
>>Sounds like it is core-dumping wihle trying to start the component :-)
>>
>>Perhaps you could post a backtrace from the core? (perhaps "gdb icqv7ext
>>-c core", then "bt".) Cores from threaded components are much nicer if
>>they are generated from something other than Linux; if you are using
>>Linux try to use the newest kernel possible (as they reworked a bit of
>>this logic within the 2.4 series)
>>
>>-David Waite
>>
>>_______________________________________________
>>jdev mailing list
>>jdev at jabber.org
>>http://mailman.jabber.org/listinfo/jdev
>>
>
>--
>-----
>FirstLink Networks - http://www.firstlinknetworks.com
>-----
>De leukste moppen op je scherm en in je mailbox : http://www.moppen.be !!!!
>
>
>_______________________________________________
>jdev mailing list
>jdev at jabber.org
>http://mailman.jabber.org/listinfo/jdev
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20020328/482bfdc1/attachment-0002.htm>