I just crashed in a timer callback with doubly freed memory: char * il_BACat (char **destination, size_t destination_length, const char *source, size_t source_length) { if (source) { if (*destination) { ==> *destination = (char *) PR_REALLOC (*destination, destination_length + source_length); if (*destination == NULL) return(NULL); nsCRT::memmove(*destination + destination_length, source, source_length); realloc_help(void * 0xdddddddd, unsigned int 0xdddddddd, int 0x00000001, const char * 0x00000000, int 0x00000000, int 0x00000001) line 614 + 3 bytes _realloc_dbg(void * 0xdddddddd, unsigned int 0xdddddddd, int 0x00000001, const char * 0x00000000, int 0x00000000) line 806 + 27 bytes realloc(void * 0xdddddddd, unsigned int 0xdddddddd) line 755 + 19 bytes PR_Realloc(void * 0xdddddddd, unsigned int 0xdddddddd) line 57 + 14 bytes il_BACat(char * * 0x0012fb14, unsigned int 0xdddddddd, const char * 0x02dc8d00, unsigned int 0x00000000) line 236 + 19 bytes il_gif_write(il_container_struct * 0x03193420, const unsigned char * 0x02dc8d00, long 0x00000000) line 1592 + 27 bytes process_buffered_gif_input_data(gif_struct * 0x03196250) line 669 + 16 bytes gif_delay_time_callback(void * 0x03193420) line 725 + 9 bytes timer_callback(nsITimer * 0x03197ec0, void * 0x031956d0) line 70 + 12 bytes nsTimer::Fire() line 194 + 17 bytes nsTimerManager::FireNextReadyTimer(nsTimerManager * const 0x020700c0, unsigned int 0x00000000) line 117 FireTimeout(HWND__ * 0x00000000, unsigned int 0x00000113, unsigned int 0x00001551, unsigned long 0x781d2d7d) line 89 USER32! 77e7185c() nsAppShellService::Run(nsAppShellService * const 0x01060ef0) line 387 main1(int 0x00000001, char * * 0x00c54190, nsISupports * 0x00000000) line 906 + 32 bytes main(int 0x00000001, char * * 0x00c54190) line 1092 + 37 bytes mainCRTStartup() line 338 + 17 bytes

Could this be related to the crash in nsFrameLoader?? bug#42724 from yesterday. If a frame is leaking and it has an animated gif associated with the frame, this might cause this to show up. I'll certainly see what I can do to make il_BACat more robust, but I'll bet the crash will then occur somewhere else.

Adding crash keyword

I don't really have a way to test this bug. No test url is given and I haven't seen the bug in over a month of viewing gifs. Please reopen if you see the bug again and ...save the url. -p

I think you're not going to see this bug unless you force the race condition. I think it's best not to close this, but perhaps push it off to Future if you can't get to it. What's needed here is some code to ensure that any timer that's started gets stopped before we shutdown services. It should be obvious from examining the code that that's not happening.

*** Bug 49785 has been marked as a duplicate of this bug. ***

Updating QA Contact

*** Bug 45902 has been marked as a duplicate of this bug. ***

All pnunn bugs reassigned to Pav, who is taking over the imglib.

saari: please take a look at this and make sure it doesn't happen with the revampd gif decoder

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

I think this bug can be closed, cause it should be resolved by the landing of the new imglib.

il_BACat was removed with the fix for bug 285872 resolving as WFM