So I guess I'm stuck ?
David Waite wrote:
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 0x8 06f6d1 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 cDavid 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
!!!!
