mldonkey, a multi-networks file-sharing client - Bugs: bug #9138, /kernel: pid xxxx (mlnet-real),...

Group

Main
- Main
- View members
- Search
Homepage
Download
Mailing lists
Source code
Bugs
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
Tasks
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
Patches
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
News
- Browse
- Atom feed
- ~~Submit~~
- ~~Manage~~

You are not allowed to post comments on this tracker with your current authentication level.

bug #9138: /kernel: pid xxxx (mlnet-real), uid 1002: exited on signal xx (core dumped)

Submitter:	None
Submitted:	Fri 28 May 2004 08:58:35 AM UTC


Category:	Core	Severity:	3 - Normal
Item Group:	Program malfunction	Status:	Works For Me
Assigned to:	None	Open/Closed:	Closed
Release:	2.7.3	Release:
Operating System:	FreeBSD	Binaries Origin:	CVS / Self compiled
CPU type:	Intel x86

Jump to the original submission

Thu 07 Dec 2006 09:33:33 AM UTC, comment #52: Since several weeks I only use BT-module and had no crashes. The version I've installed is from ports, which is synced with the CVS version from 2006/11/21. I compiled my last upgrades WITHOUT_THR_THREAD_MODEL. As I haven't used the edonkey-module in the last time, I can't say if the crashes are gone forever now. I would propose to close this bug-report for now. I will try to reopen it, if this would be neccessary. Greetings, raXion	raXion <raXion>
Wed 06 Dec 2006 09:44:15 PM UTC, comment #51: Please check if this bug still is in current CVS version.	spiralvoice <spiralvoice>
Tue 14 Nov 2006 08:29:43 PM UTC, comment #50: What happens when you compile MLDonkey without WITH_THR_THREAD_MODEL="YES"	spiralvoice <spiralvoice>
Tue 07 Nov 2006 09:18:33 PM UTC, comment #49: Please check if this bug still is in current CVS version. You should find a tarball of current CVS in files section of this project: http://download.berlios.de/pub/mldonkey/spiralvoice/	spiralvoice <spiralvoice>
Sun 16 Jul 2006 12:56:15 AM UTC, comment #48: Is this bug still valid? Did you ever test MLDonkey on a fresh install of FreeBSD?	spiralvoice <spiralvoice>
Mon 13 Feb 2006 02:02:00 PM UTC, comment #47: The gdb-backtrace seems to be the same: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `mlnet-real'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libcharset.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcharset.so.1 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/lib/libbz2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.2 Reading symbols from /usr/local/lib/libgd.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgd.so.4 Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libjpeg.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libjpeg.so.9 Reading symbols from /usr/local/lib/libpng.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpng.so.5 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /usr/lib/libstdc++.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /usr/lib/libpthread.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpthread.so.2 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x08324125 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () [New LWP 100076] (gdb) backtrace #0 0x08324125 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #1 0x083244fa in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #2 0x0833036e in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #3 0x08324471 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #4 0x08324aa1 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #5 0x08324beb in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #6 0x083309de in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #7 0x08329041 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #8 0x0828adab in ?? () #9 0x0bb55000 in ?? () #10 0x08187851 in ?? () #11 0xbfbfeb44 in ?? () #12 0x081877ec in ?? () #13 0x00000083 in ?? () #14 0x08d9b910 in ?? () #15 0x000004b0 in ?? () #16 0x08187a35 in ?? () #17 0xbfbfeb64 in ?? () #18 0x081879b5 in ?? () #19 0x08d9b910 in ?? () #20 0x0b5f8790 in ?? () #21 0x0828fbef in ?? () #22 0x094444b4 in ?? () #23 0x085157bc in ?? () #24 0x081328b8 in ?? () #25 0xbfbfeb6c in ?? () #26 0x0813282f in ?? () #27 0xbfbfeb98 in ?? () #28 0x0813247c in ?? () #29 0x085157bc in ?? () #30 0x00000001 in ?? () #31 0x08dec610 in ?? () #32 0x08df1dfc in ?? () #33 0x08515b10 in ?? () #34 0x09444d54 in ?? () #35 0x08515848 in ?? () #36 0x08e529b0 in ?? () #37 0x08132ec6 in ?? () #38 0xbfbfebb8 in ?? () #39 0x08132c2a in ?? () #40 0x08dec610 in ?? () #41 0x00000000 in ?? () #42 0x0b5f8774 in ?? () #43 0x0b5f8744 in ?? () #44 0x0b5f8708 in ?? () #45 0x0817459c in ?? () #46 0xbfbfebf4 in ?? () #47 0x08174520 in ?? () #48 0x085159a8 in ?? () #49 0x08743a18 in ?? () #50 0x087e25d0 in ?? () #51 0x0828f5ca in ?? () #52 0x087e1bfc in ?? () #53 0x0b5f86f8 in ?? () #54 0x0817f7d6 in ?? () #55 0x08515b10 in ?? () #56 0x08515a38 in ?? () #57 0x08515bd4 in ?? () #58 0x00000001 in ?? () ---Type <return> to continue, or q <return> to quit--- #59 0x088335d4 in ?? () #60 0x0817f109 in ?? () #61 0xbfbfebfc in ?? () #62 0x0817f015 in ?? () #63 0xbfbfec24 in ?? () #64 0x0817ed97 in ?? () #65 0x08516f18 in ?? () #66 0x08517048 in ?? () #67 0x0b57110c in ?? () #68 0x0b5f86bc in ?? () #69 0x0828f5ca in ?? () #70 0x0b56e0fc in ?? () #71 0x0b57110c in ?? () #72 0x0817fda0 in ?? () #73 0xbfbfec54 in ?? () #74 0x0817fcbb in ?? () #75 0x0851159c in ?? () #76 0x089df138 in ?? () #77 0x083f87a0 in __progname () #78 0x0002e005 in ?? () #79 0x0002e003 in ?? () #80 0x00017013 in ?? () #81 0x08743a88 in ?? () #82 0x088335d4 in ?? () #83 0x0b5710f0 in ?? () #84 0x082606e7 in ?? () #85 0xbfbfec6c in ?? () #86 0x082606cd in ?? () #87 0x0b589a58 in ?? () #88 0x082603c1 in ?? () #89 0x08705b88 in ?? () #90 0x08260903 in ?? () #91 0xbfbfec98 in ?? () #92 0x08260756 in ?? () #93 0x0b58b7e0 in ?? () #94 0x0a44f968 in ?? () #95 0x72b9dfad in ?? () #96 0x41d0fc23 in ?? () #97 0x00000000 in ?? () #98 0xbf8e52a0 in ?? () #99 0x08050bcb in ?? () #100 0x0804e355 in ?? () #101 0x0833100e in std::operator+<char, std::char_traits<char>, std::allocator<char> > () Previous frame inner to this frame (corrupt stack?) (gdb)	raXion <raXion>
Mon 13 Feb 2006 09:44:15 AM UTC, comment #46: I recompiled MLDonkey with the following options (hoping this will produce better backtraces): make WITHOUT_THR_THREAD_MODEL="YES" WITHOUT_GUI="YES" CONFIGURE_ARGS="--enable-debug --disable-pthread"	raXion <raXion>
Mon 13 Feb 2006 09:35:32 AM UTC, comment #45: I did, and I also get core dumps ;-(. What should I do now?	raXion <raXion>
Sun 12 Feb 2006 03:59:55 PM UTC, comment #44: Did you ever try if libpthread produces the same core dump?	spiralvoice <spiralvoice>
Sun 12 Feb 2006 03:04:17 PM UTC, comment #43: MLDonkey was made using the following command-line: make clean && make WITH_THR_THREAD_MODEL="YES" WITHOUT_GUI="YES" CONFIGURE_ARGS="--enable-debug --enable-checks" Should I avoid WITH_THR_THREAD_MODEL="YES" (which results in using libthr and not libpthread) and use WITHOUT_THR_THREAD_MODEL="YES" instead?	raXion <raXion>
Sat 11 Feb 2006 12:27:09 AM UTC, comment #42: um i can't read anything usefull in this backtrace. was mldonkey compiled with debugsymbols ( --enable-debug )?	Amorphous <amorphous>
Wed 08 Feb 2006 08:22:12 AM UTC, comment #41: I used gdb with the generated core-file 'gdb -c mlnet-real.core /usr/local/bin/mlnet-real': (How can I determine to which port the libraries at the beginning of the bakctrace belong?) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"..."/usr/home/mldonkey/.mldonkey/mlnet-real.core": not in executable format: File format not recognized (gdb) backtrace No stack. (gdb) exit Undefined command: "exit". Try "help". (gdb) quit susi# gdb -c mlnet-real.core /usr/local/bin/mlnet-real GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `mlnet-real'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libcharset.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcharset.so.1 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/lib/libbz2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.2 Reading symbols from /usr/lib/libthr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthr.so.2 Reading symbols from /usr/lib/libstdc++.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x083226b8 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () [New Thread 0x84da200 (LWP 100097)] [New Thread 0x84da000 (LWP 100118)] (gdb) bt #0 0x083226b8 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #1 0x0832293d in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #2 0x08322e17 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #3 0x08316e51 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #4 0x08317471 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #5 0x083175bb in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #6 0x0832341e in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #7 0x0831ba31 in std::operator+<char, std::char_traits<char>, std::allocator<char> > () #8 0x0827ea6b in ?? () #9 0x0be87000 in ?? () #10 0x0818bc61 in ?? () #11 0xbfbfeb44 in ?? () #12 0x0818bbfc in ?? () #13 0x0000002d in ?? () #14 0x00004ff3 in ?? () #15 0x00000007 in ?? () #16 0x0818be45 in ?? () #17 0xbfbfeb64 in ?? () #18 0x0818bdc5 in ?? () #19 0xbfbfeb38 in ?? () #20 0x00000bff in ?? () #21 0x082838af in ?? () #22 0x08d07d48 in ?? () #23 0x084f835c in ?? () #24 0x081365a8 in ?? () #25 0xbfbfeb6c in ?? () #26 0x0813651f in ?? () #27 0xbfbfeb98 in ?? () #28 0x0813616c in ?? () #29 0x084f835c in ?? () #30 0x00000001 in ?? () #31 0x00001003 in ?? () #32 0x089c0568 in ?? () #33 0x084f86b8 in ?? () #34 0x00002803 in ?? () #35 0x084f83f0 in ?? () #36 0x08a55784 in ?? () #37 0x08136bb6 in ?? () #38 0xbfbfebb8 in ?? () #39 0x0813691a in ?? () #40 0x089c7528 in ?? () #41 0x00000000 in ?? () #42 0x00000fff in ?? () #43 0x00003ff3 in ?? () #44 0x00004ff3 in ?? () #45 0x081789ec in ?? () #46 0xbfbfebf4 in ?? () #47 0x08178970 in ?? () #48 0x084f8550 in ?? () #49 0x08728818 in ?? () #50 0x083bcc0c in __progname () #51 0x0828328a in ?? () #52 0x00000803 in ?? () #53 0x00000fdf in ?? () #54 0x08183be6 in ?? () #55 0x084f86b8 in ?? () #56 0x084f85e0 in ?? () #57 0x084f87b0 in ?? () #58 0x00000001 in ?? () ---Type <return> to continue, or q <return> to quit--- #59 0x087805e0 in ?? () #60 0x08183519 in ?? () #61 0xbfbfebfc in ?? () #62 0x08183425 in ?? () #63 0xbfbfec24 in ?? () #64 0x081831a7 in ?? () #65 0x084f9bc8 in ?? () #66 0x084f9cf8 in ?? () #67 0x0b3816b8 in ?? () #68 0x00004ff3 in ?? () #69 0x0828328a in ?? () #70 0x00000803 in ?? () #71 0x00002bdf in ?? () #72 0x081841b0 in ?? () #73 0xbfbfec54 in ?? () #74 0x081840cb in ?? () #75 0x084f46ac in ?? () #76 0x08ab1a84 in ?? () #77 0x083ea02c in __progname () #78 0x0002e005 in ?? () #79 0x0002e003 in ?? () #80 0x00017013 in ?? () #81 0x08728888 in ?? () #82 0x087805e0 in ?? () #83 0x00001bf3 in ?? () #84 0x08253bd7 in ?? () #85 0xbfbfec6c in ?? () #86 0x08253bbd in ?? () #87 0x00000803 in ?? () #88 0x082538b1 in ?? () #89 0x086e7814 in ?? () #90 0x08253df3 in ?? () #91 0xbfbfec98 in ?? () #92 0x08253c46 in ?? () #93 0x084f00e4 in ?? () #94 0x09ae637c in ?? () #95 0xf4e9d74d in ?? () #96 0x41d0fa57 in ?? () #97 0x00000000 in ?? () #98 0xbf80d940 in ?? () #99 0x0805053b in ?? () #100 0x0804de79 in ?? () #101 0x08323a4e in std::operator+<char, std::char_traits<char>, std::allocator<char> > () Previous frame inner to this frame (corrupt stack?) (gdb)	raXion <raXion>
Sun 22 Jan 2006 12:23:21 AM UTC, comment #40: please get a backtrace. after you get "Program received signal SIGSEGV..." type in the command bt.	Amorphous <amorphous>
Fri 20 Jan 2006 03:54:48 PM UTC, comment #39: Hi, here is what I've done and what output I got. It doesn't seem to say very much to me. Did I used gdb right at all? --------------------------------------------------- 5707 p0 RN 6:48.59 /usr/local/bin/mlnet-real ... susi# gdb /usr/local/bin/mlnet-real 5707 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/bin/mlnet-real, process 5707 Reading symbols from /usr/local/lib/libcharset.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libcharset.so.1 Reading symbols from /lib/libz.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/lib/libbz2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.2 Reading symbols from /usr/lib/libstdc++.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/libm.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /usr/lib/libpthread.so.2...(no debugging symbols found)...done. warning: Unable to get location for thread creation breakpoint: generic error [New Thread 0x84f0800 (sleeping)] [New Thread 0x84f0600 (LWP 100143)] [New Thread 0x84f0000 (runnable)] [New LWP 100553] Loaded symbols for /usr/lib/libpthread.so.2 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to LWP 100553] 0x2858c14b in pthread_testcancel () from /usr/lib/libpthread.so.2 (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) n Program not restarted. (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x84f0000 (LWP 100200)] 0xf7c81c08 in ?? () (gdb) Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) susi#	raXion <raXion>
Fri 20 Jan 2006 02:07:49 PM UTC, comment #38: I still have random core dumps of mldonkey. Right now I'm using FreeBSD-6.0-RELEASE and MLDonkey 2.7.3. I will try to debug MLD using gdb (I have compiled it with "--enable-debug").	raXion <raXion>
Mon 21 Nov 2005 09:15:27 PM UTC, comment #37: Please check if this bug still is in current CVS version. You should find a tarball of current CVS in files section of this project: http://download.berlios.de/pub/mldonkey/spiralvoice/	spiralvoice <spiralvoice>
Sat 23 Jul 2005 12:58:32 PM UTC, comment #36: Does that patch print out the function backtrace when the application does an segv? The only thing you need to do is add b to that env. variabl? I guess it would be easier to just use gdb, as you don't need to patch ocaml for this. This should work exactly like you would debug any other C code that does an segv. I'm not sure, but i guess the needed debug-symbols are already in the binary when compiled with --enable-debug .	Amorphous <amorphous>
Fri 22 Jul 2005 10:39:49 AM UTC, comment #35: Thanks. I will try to patch OCAML, in the way sprialvoice' link proposes and test it with MLD 2.6.0. It's there. Greetings! Maybe I can provide more info after that.	raXion <raXion>
Thu 21 Jul 2005 03:54:13 PM UTC, comment #34: Maybe this can help: "Patch for native function backtraces" http://article.gmane.org/gmane.comp.lang.caml.inria/29692	spiralvoice <spiralvoice>
Tue 19 Jul 2005 06:13:03 PM UTC, comment #33: You could try to use gdb on mldonkey (and try to get an backtace), but i can't tell you from my head how to do that. Perhaps someone else can say how to exactly do that. Otherwise i will try, when i have time for mldonkey again.	Amorphous <amorphous>
Tue 19 Jul 2005 05:28:07 PM UTC, comment #32: I guess you did it the right way. It seems it is not possible to get an backtrace from an segv-ing application in that way. Perhaps the segv occurs in some c-code and not in the ocaml part? I hope someone else has some more insight how to procede here.	Amorphous <amorphous>
Tue 19 Jul 2005 08:56:59 AM UTC, comment #31: After crashing I can only kill the debugger to get out. It makes no difference wheter I enter 'y' or 'n' in the debugger after crash: I only get the same question every time. (See the end of my last post.) Did I call 'ocamldebug' the right way?	Anonymous
Fri 10 Jun 2005 11:16:14 AM UTC, comment #30: I couldn't get the backtrace! $ ocamldebug $(find /home/mldonkey/mldonkey-core-devel/work/mldonkey-2.5.30.15/src -name '.*' -prune -o -name 'gtk' -prune -o -name 'applets' -prune -o -d -printf '-l %p') ./mlnet.byte find: -d: unknown option Objective Caml Debugger version 3.08.3 (ocd) set checkpoints off (ocd) run Loading program... done. Current locale of the target machine is ASCII Current language of the target machine is EN List of charmap used to convert the strings: Use encoding CP1252 Use encoding ISO-8859-15 Use encoding 850 Use encoding CP819 Use encoding MAC Use encoding 437 Use encoding 860 Use encoding 863 Use encoding ANSI_X3.4-1968 Use encoding C99 Use encoding ISO-10646-UCS-2 Use encoding UCS-2BE Use encoding UCS-2LE Use encoding ISO-10646-UCS-4 Use encoding UCS-4BE Use encoding UCS-4LE Use encoding UTF-16 Use encoding UTF-16BE Use encoding UTF-16LE Use encoding UTF-32 Use encoding UTF-32BE Use encoding UTF-32LE Use encoding UNICODE-1-1-UTF-7 Use encoding UCS-2-INTERNAL Use encoding UCS-2-SWAPPED Use encoding UCS-4-INTERNAL Use encoding UCS-4-SWAPPED No /home/mldonkey/.mldonkey/installer.ini found The .ini-files are saved in /usr/home/mldonkey/.mldonkey Resolving [susi.redhill.net] ...done Network Global Shares registered Network Gnutella registered Network G2 registered Network Fasttrack registered Network FileTP registered Network BitTorrent registered Network Donkey registered Resolving www.mldonkey.net ...done IP blacklist: 81401 ranges loaded Logging in mldonkey.log Segmentation fault (core dumped) Lost connection with process 23773 (active process) between time 25396550000 and time 25396560000 Trying to recover... Can't go that far in the past ! Reload program ? (y or n) n Trying to recover... Can't go that far in the past ! Reload program ? (y or n) n Trying to recover... Can't go that far in the past ! Reload program ? (y or n) n Trying to recover... Can't go that far in the past ! Reload program ? (y or n) no Trying to recover... Can't go that far in the past ! Reload program ? (y or n) n [...]	raXion <raXion>
Tue 07 Jun 2005 02:57:08 PM UTC, comment #29: I started wit ocamldebug and it seems to work. Only your option "printf '-l %p'" doesn't work. Is this critical for debugging? Here's the output I got: $ ocamldebug $(find /home/mldonkey/mldonkey-core-devel/work/mldonkey-2.5.30.15/src -name '.*' -prune -o -name 'gtk' -prune -o -name 'applets' -prune -o -d -printf '-l %p') ./mlnet.byte find: -printf: unknown option Objective Caml Debugger version 3.08.3 (ocd) set checkpoints off (ocd) run Loading program... done. Current locale of the target machine is ASCII Current language of the target machine is EN List of charmap used to convert the strings: Use encoding CP1252 Use encoding ISO-8859-15 Use encoding 850 Use encoding CP819 Use encoding MAC Use encoding 437 Use encoding 860 Use encoding 863 Use encoding ANSI_X3.4-1968 Use encoding C99 Use encoding ISO-10646-UCS-2 Use encoding UCS-2BE Use encoding UCS-2LE Use encoding ISO-10646-UCS-4 Use encoding UCS-4BE Use encoding UCS-4LE Use encoding UTF-16 Use encoding UTF-16BE Use encoding UTF-16LE Use encoding UTF-32 Use encoding UTF-32BE Use encoding UTF-32LE Use encoding UNICODE-1-1-UTF-7 Use encoding UCS-2-INTERNAL Use encoding UCS-2-SWAPPED Use encoding UCS-4-INTERNAL Use encoding UCS-4-SWAPPED No /home/mldonkey/.mldonkey/installer.ini found The .ini-files are saved in /usr/home/mldonkey/.mldonkey Resolving [susi.redhill.net] ...done Network Global Shares registered Network Gnutella registered Network G2 registered Network Fasttrack registered Network FileTP registered Network BitTorrent registered Network Donkey registered Resolving www.mldonkey.net ...done IP blacklist: 81401 ranges loaded Logging in mldonkey.log	raXion <raXion>
Sun 05 Jun 2005 03:57:04 PM UTC, comment #28: You get mlnet.byte by the following command after you did run configure: make mlnet.byte Get an backtrace: Just type in "bt" in the debugger and then for each number after # type in "frame NUM" (replace NUM). Output looks similar to the example given.	Amorphous <amorphous>
Sun 05 Jun 2005 03:27:04 PM UTC, comment #27: Where did I find mlnet.byte? After running 'find / -name "*.byte"' I only got: /root/mldonkey-core-devel/work/mldonkey-2.5.30.15/ocamlpp.byte /root/mldonkey-core-devel/ is my very own copy of /usr/ports/mldonkey-core-devel. Your last part "What to do after crash" didn't say anything to me ;-(( Maybe you can repeat this.	raXion <raXion>
Fri 03 Jun 2005 02:49:42 PM UTC, comment #26: copy mlnet.byte to your mldonkey directory and cd into it execute the debugger as follows and replace "/path/to/src/" with the path to the directory src in the mldonkey sources: ocamldebug $(find /path/to/src/ -name '.*' -prune -o -name 'gtk' -prune -o -name 'gtk2' -prune -o -name 'applets' -prune -o -type d -printf '-I %p ') ./mlnet.byte then type the following in the debugger: set checkpoints off run then wait until the problem occurs and type the following (however i don't know if the debugger will just be killed, like mlnet.) (if mlnet didn't halt into the debugger interrupt it with ctrl-c.): bt then for each # greater than 0 type (and replace # with the number): frame # example for the last part: (ocd) bt #0 Pc : 6160 Test char 22 #1 Pc : 6160 Test char 22 #2 Pc : 6160 Test char 22 (ocd) frame 1 #1 Pc : 6160 Test char 22 2 <\|b\|>test () (ocd) frame 2 #2 Pc : 6160 Test char 22 2 <\|b\|>test ()	Amorphous <amorphous>
Thu 02 Jun 2005 03:23:47 PM UTC, comment #25: Here's my output of make. Downloads are running only from the donkey network (and sometimes from BT). How do I run an bytecode mldonkey in the debugger???	Anonymous
Wed 01 Jun 2005 08:01:30 AM UTC, comment #24: Could you tell us the output of buildinfo ? From what networks do you have downloads running? If none of these are likely to show why that happens, I guess you could use --enable-debug (that compiles in debug symbols) and run an bytecode mldonkey in the debugger. Perhaps we are then able to see where the segmentation fault happens.	Amorphous <amorphous>
Tue 31 May 2005 10:32:03 AM UTC, comment #23: I had six core-dumps since my last post, 5 days ago.	raXion <raXion>
Thu 26 May 2005 10:19:01 AM UTC, comment #22: The recompiled binary is running now ... Is it useful to also --enable-debug? These modules are activated: Global Shares Gnutella G2 Fasttrack FileTP BitTorrent Donkey	raXion <raXion>
Tue 24 May 2005 03:16:42 PM UTC, comment #21: Please try compiling with --enable-checks Which network modules are activated?	spiralvoice <spiralvoice>
Tue 24 May 2005 10:54:51 AM UTC, comment #20: I still get those core dumps with the following environment: FreeBSD 5.4-STABLE MLDonkey 2.5.30.15 (compiled from ports WITHOUT_GUI=yes WITH_THR_THREAD_MODEL=no) I'm using guarding.p2p from openmedia.info $ ulimit -a cpu time (seconds, -t) unlimited file size (512-blocks, -f) unlimited data seg size (kbytes, -d) 524288 stack size (kbytes, -s) 65536 core file size (512-blocks, -c) unlimited max memory size (kbytes, -m) unlimited locked memory (kbytes, -l) unlimited max user processes (-u) 5547 open files (-n) 32768 virtual mem size (kbytes, -v) unlimited sbsize (bytes, -b) unlimited Last core dumps since yesterday: May 23 08:34:43 susi kernel: pid 10946 (mlnet-real), uid 1005: exited on signal 11 (core dumped) May 23 12:45:18 susi kernel: pid 54534 (mlnet-real), uid 1005: exited on signal 11 (core dumped) May 23 21:24:00 susi kernel: pid 94348 (mlnet-real), uid 1005: exited on signal 11 (core dumped) May 24 00:26:53 susi kernel: pid 29954 (mlnet-real), uid 1005: exited on signal 11 (core dumped) May 24 09:02:31 susi kernel: pid 37092 (mlnet-real), uid 1005: exited on signal 11 (core dumped)	raXion <raXion>
Wed 16 Mar 2005 02:22:19 AM UTC, comment #19: does this still happen?	Amorphous <amorphous>
Fri 01 Oct 2004 02:03:10 PM UTC, comment #18: 'ulimit' says 'umlimited', if started as my MLD-user. After the core dumps mentioned underneath, I only got one on 'Sep 29 14: ...'. Since two days mlnet works fine. Isn't it strange?	raXion <raXion>
Fri 01 Oct 2004 01:09:14 PM UTC, comment #17: Use ulimit	spiralvoice <spiralvoice>
Wed 29 Sep 2004 11:42:39 AM UTC, comment #16: I have enabled this networks: Overnet, Donkey, Bittorrent, Fastrack and FileTP. But I got 5 core-dumps during the last 2 days, all after 3 to 4 hours after starting the mlnet-core. susi# grep mlnet /var/log/messages Sep 28 20:50:50 susi kernel: pid 84537 (mlnet-real), uid 1005: exited on signal 11 (core dumped) Sep 28 23:53:42 susi kernel: pid 86825 (mlnet-real), uid 1005: exited on signal 11 (core dumped) Sep 29 03:09:14 susi kernel: pid 88172 (mlnet-real), uid 1005: exited on signal 11 (core dumped) Sep 29 07:43:14 susi kernel: pid 90167 (mlnet-real), uid 1005: exited on signal 11 (core dumped) Sep 29 11:47:49 susi kernel: pid 92414 (mlnet-real), uid 1005: exited on signal 11 (core dumped) susi# How do I check those RAM-limits?	raXion <raXion>
Thu 19 Aug 2004 12:56:22 PM UTC, comment #15: Please pay also attention to the RAM limits for the MLDonkey process imposed by ulimit.	spiralvoice <spiralvoice>
Thu 19 Aug 2004 12:03:13 PM UTC, comment #14: Today I updated to 2.5.28.	raXion <raXion>
Tue 17 Aug 2004 11:15:16 AM UTC, comment #13: I changed ulimit settings according to http://support.zeus.com/faq/zlb/v1/entries/os/freebsd.html . I have autoconf-2.59 installed ... I also disabled both Gnutella-Networks.	raXion <raXion>
Sun 15 Aug 2004 03:51:49 PM UTC, comment #12: Please check ulimit settings for mlnet, they tend to be pretty tight on FreeBSD, also install autoconf-2.59 to compile the core.	spiralvoice <spiralvoice>
Wed 11 Aug 2004 04:43:42 PM UTC, comment #11: I would like to, but this depends on bugs #9795 for me.	raXion <raXion>
Tue 10 Aug 2004 11:04:12 AM UTC, comment #10: Please check with current CVS versions, also please check whether there is a small ulimit for MLDonkey regarding memory.	spiralvoice <spiralvoice>
Tue 27 Jul 2004 01:00:56 PM UTC, comment #9: I have 1536 MB of RAM installed and there is always free memory available. I also have all networks enabled, including Gnutella. I will disable Gnutella and check if got a core dump again.	Anonymous
Thu 22 Jul 2004 11:25:45 PM UTC, comment #8: Please check whether MLDonkey uses too much RAM and dies when no free RAM is available anymore. What networks are enabled and used? Some of them have known memory leaks (Gnutella for example), take a look at the other bug reports.	spiralvoice <spiralvoice>
Thu 01 Jul 2004 12:16:29 PM UTC, comment #7: Today I ran Memtest v3.0 from Boot-CD and the standard test run (took about 90 minutes) didn't report any errors. So what next? It seems to me my memory is good.	Anonymous
Thu 17 Jun 2004 12:27:07 PM UTC, comment #6: CPU fan is working. I ran `memtest all 4 -l` (/usr/ports/sysutils/memtest) but received no errors. I will try memtest86 from boot CD later. Also my memory speed settings are set to conservative "normal", which is the slowest possible setting.	Anonymous
Sat 05 Jun 2004 07:19:58 AM UTC, comment #5: Try this for memory test: http://www.memtest86.com/ Is CPU fan working?	Anonymous
Thu 03 Jun 2004 10:09:52 PM UTC, comment #4: Good to hear that. My CPU is not overclocked, but maybe I should try some more conservative memory speed settings. It's set to the default "normal", I think, but I will check this ...	Anonymous
Wed 02 Jun 2004 09:05:54 PM UTC, comment #3: This signals mostly related to bad memory or overclocking. I use the same OS but on a good old Celeron 300A without any probs. FreeBSD 4.10-PRERELEASE #0: Wed May 19 02:40:19 CEST 2004 root@pass:/usr/obj/usr/src/sys/pass CPU: Pentium II/Pentium II Xeon/Celeron (298.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR> real memory = 301989888 (294912K bytes) avail memory = 290680832 (283868K bytes) 34785 ?? SNs 972:43.46 /usr/local/bin/mlnet-real ...	Artifex Maximus <artifex>
Mon 31 May 2004 10:08:47 PM UTC, comment #2: I've attached the output of `grep mlnet-real` /var/log/messages` as mlnet-dies.txt. It seems that mlnet-real dies at least once a day. Currently we have a total of 35 files in download, in sum 20 GB.	Anonymous
Sat 29 May 2004 06:07:40 PM UTC, comment #1: Do you know under which circumstances the core dies? How long did the core run?	spiralvoice <spiralvoice>
Fri 28 May 2004 08:58:35 AM UTC, original submission: From time to time I get one of the two messages after mlnet-real died: /kernel: pid xxxx (mlnet-real), uid 1002: exited on signal 10 (core dumped) /kernel: pid xxxx (mlnet-real), uid 1002: exited on signal 11 (core dumped) You will find FreeBSD version and memory information in the attached file. MLDonkey was built using the ports system.	Anonymous

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

file #3028: make.txt added by None (190KiB - text/plain - Output of make.)

file #1368: mlnet-dies[1].txt added by None (2KiB - text/plain - Output of `grep mlnet-real`.)

file #1356: part_of_my_messages.txt added by None (1KiB - text/plain - An excerpt of my /var/log/messages)

Depends on the following items: None found

Items that depend on this one: None found

Carbon-Copy List

-email is unavailable- added by raXion (Posted a comment)

-email is unavailable- added by spiralvoice (Posted a comment)

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Follow 14 latest changes.

Date	Changed by	Updated Field	Previous Value	Replaced by
2006-12-07	spiralvoice	Status	Need Info	Works For Me
		Open/Closed	Open	Closed
2006-06-23	spiralvoice	Release	2.5.30.15	2.7.3
2005-07-19	beedauchon	Status	None	Need Info
2005-06-02	None	Attached File	-	Added make.txt, #2560
2005-05-24	spiralvoice	Status	Fixed	None
		Open/Closed	Closed	Open
		Release	2-5-21	2.5.30.15
		Release	2.5.-21
2005-04-12	spiralvoice	Open/Closed	Open	Closed
2005-03-16	amorphous	Status	None	Fixed
2004-07-29	raXion	Carbon-Copy	-	Added raxion
2004-05-31	None	Attached File	-	Added mlnet-dies[1].txt, #1360
2004-05-28	None	Attached File	-	Added part_of_my_messages.txt, #1348

mldonkey, a multi-networks file-sharing client - Bugs: bug #9138, /kernel: pid xxxx (mlnet-real),...

bug #9138: /kernel: pid xxxx (mlnet-real), uid 1002: exited on signal xx (core dumped)

<a href="#discussion">Discussion</a>

<a href="#attached">Attached Files</a>

<a href="#dependencies">Dependencies</a>

<a href="#cc">Mail Notification Carbon-Copy List</a>

<a href="#votes">Votes</a>

<a href="#history">History</a>