Carl, I no longer work on gtk-gnutella. I'm forwarding your message to the gtkg-devel list.
Raphael ----- Forwarded message from Carl Erhorn <[EMAIL PROTECTED]> ----- Date: Mon, 29 Sep 2003 11:42:20 -0400 From: "Carl Erhorn" <[EMAIL PROTECTED]> Subject: Support request To: <[EMAIL PROTECTED]> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Hi, Raphael. I did additional research into the problem I am seeing, and found that the problem is happening only when someone tries to upload one of my files. If I remove all files from the upload list, the program appears to stay running forever. I turned up the debug parameters for core and gui to 9, and directed the output to a file, which I have available, but it's huge. I also have the core file that corresponds to this error. The last entry in the log says: 03/09/29 11:13:59 (WARNING): adns_do_transfer: EOF (read) and the core traceback says: [EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (no mapping at the fault address) 0xdf06d3b1: strlen+0x000d: repnz scasb %al,(%edi) Current function is g_io_unix_dispatch 161 user_data); (dbx) where [1] strlen(0x817d488), at 0xdf06d3b1 [2] _doprnt(0x817d488, 0x8046ae4, 0x8046a9c), at 0xdf09d90e [3] vsnprintf(0x8046af0, 0x400, 0x817d488, 0x8046ae4), at 0xdf09f343 [4] gm_snprintf(0x8046af0, 0x400, 0x817d488, 0xd5c1b65d, 0x0), at 0x80e87ae [5] 0x810b3b1(0x84bc1a8), at 0x810b3b0 [6] parq_upload_lookup_queue_no(0x84bc1a8), at 0x810cd8b [7] upload_get_status(0x0, 0x8046f30), at 0x81321ae [8] 0x80b368e(0x8851c98), at 0x80b368d [9] 0x80b3077(0x0, 0x0, 0x1), at 0x80b3076 [10] 0x812ef69(0x84bc1a8), at 0x812ef68 [11] upload_create(0x8818800, 0x0), at 0x812f1f0 [12] upload_add(0x8818800), at 0x813019f [13] 0x81239f2(0x8818800, 0xa, 0x1), at 0x81239f1 [14] 0x80fb52d(0x86d5240, 0x1, 0x86826f0), at 0x80fb52c =>[15] g_io_unix_dispatch(source = 0x85c5800, callback = 0x80fb4e7, user_data = 0x86826f0), line 161 in "giounix.c" [16] g_main_dispatch(context = 0x8360668), line 1753 in "gmain.c" [17] g_main_context_dispatch(context = 0x8360668), line 2299 in "gmain.c" [18] g_main_context_iterate(context = 0x8360668, block = 1, dispatch = 1, self = 0x835da38), line 2380 in "gmain.c" [19] g_main_loop_run(loop = 0x85b7438), line 2600 in "gmain.c" [20] gtk_main(), line 1093 in "gtkmain.c" [21] main_gui_run(), at 0x80c5e8b [22] main(0x1, 0x8047214, 0x804721c), at 0x80fc8aa (dbx) So it appears that someone requested a file, and while attempting to send the file, I encounter the error. I believe now that the IP address that matched an entry in the hostiles.txt file probably had nothing to do with the core dump. I think I jumped to conclusions on the cause, because of the error message I saw. It has not repeated, but the core dumps are regular, usually within 10 minutes of startup. And after three of them, they all end exactly like the one above. Somehow we are giving an invalid address to strlen, passing it an address that does not belong to the program, which caused the segment fault. Can you shed any light on this? I suspect it may be due to porting problems. I mentioned in my previous message that the code is running on a Solaris 8 X86 system, with dual CPUs, and 512MB of ram, plus another 2GB of virtual memory on disk. I am using the X-Windows/Motif that comes with Solaris 8. The system is patched up to date, and has been stable for about 2 years. The program and all support libraries were built with the SUN Forte 6.2 C compiler, which is why porting was needed. I cannot install gcc/g++ on this system, because of business requirements. Unless you have seen similar problems during your testing, I suspect it's a porting error, and I will have to dig into the code to find what's wrong. Any information you could give on the possible reasons for the problem, or any hints on how the code works in the traceback functions above would be a big help, since I have not read the code yet, and don't know when I would have time to really learn the code. It looks pretty obvious that the problem occurs in these code functions: [1] strlen [2] _doprnt [3] vsnprintf [4] gm_snprintf [5] 0x810b3b1 [6] parq_upload_lookup_queue_no [7] upload_get_status [8] 0x80b368e [9] 0x80b3077 [10] 0x812ef69 [11] upload_create [12] upload_add So we must be creating a queue entry for the upload at the time of the crash. In particualr, I think the queue has been created, and we are looking for the queue number of the queue associated with the request. If that's true, perhaps the rest of the function calls are just to log the new queue entry. If that's true too, then this should be fairly easy to find and fix. But as I said, I have not read the source code yet, so this is only a guess based on the traceback. Please let me know if there is any additional info I can provide. Regards, --Carl Erhorn <[EMAIL PROTECTED]> ----- End forwarded message ----- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
