GNOME Bugzilla – Bug 343257
Pan crashes periodically
Last modified: 2006-06-27 15:21:06 UTC
Steps to reproduce: I've queued up a bunch of stuff to download. Pan runs for a while, then, just disappears! It doesn't seem to be linked to any action I'm taking. If I start it again, it picks where it left off, runs for a while, then, gone... Stack trace: Script started on Sun 28 May 2006 02:07:06 PM PDT [root@einstein tmp]# uname -a Linux einstein.address4life.com 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006 i686 i686 i386 GNU/Linux [root@einstein tmp]# gdb pan GNU gdb Red Hat Linux (6.3.0.0-1.122rh) 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-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) handle SIGUSR1 nostop noprint Signal Stop Print Pass to program Description SIGUSR1 No No Yes User defined signal 1 (gdb) handle SIG32 nostop noprint Signal Stop Print Pass to program Description SIG32 No No Yes Real-time event 32 (gdb) run Starting program: /usr/bin/pan Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x70c000 [Thread debugging using libthread_db enabled] [New Thread -1208453456 (LWP 26572)] terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Program received signal SIGABRT, Aborted. [Switching to Thread -1208453456 (LWP 26572)] 0x0070c402 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 68503
Thread 1 (Thread -1208453456 (LWP 26572))
The program is running. Exit anyway? (y or n) y [root@einstein tmp]# exit Script done on Sun 28 May 2006 05:30:55 PM PDT Other information:
*** Bug 343305 has been marked as a duplicate of this bug. ***
I haven't been able to duplicate this bug. Alen, do you have any suggestions on how to reproduce this?
ping: Alen
Sorry Charles, I have no reliable way to reproduce this. I tried when it was happeneing, but couldn't figure out how or why to reproduece it at will.
Hm, looking over this bug again, it doesn't seem mysterious at all. It looks like needed->part.bytes is somehow getting corrupted -- or maybe we got a bad value for it from the news server -- so we're trying to preallocate a too-large number of bytes in needed->buf. I'll double-check to make sure we save and reload the byte count properly, but regardless Pan needs a safety check in here in case the value we got back from the server is incorrect.
According to inn.conf(5), inn's default maximum article size is 1,000,000. IMO that would be a good upper limit for preallocating the article buffer. (it's a vector, so it will resize more if it needs to).
Created attachment 68054 [details] [review] don't pass too many bytes into buf.reserve(bytes); This patch uses 1000000 as the maximum prealloc size because that's INN's default maximum article size.
I manually corrupted the `bytes' field of a few articles in one of Pan's data files and then tried to view them, and the patch is working correctly.