This seems to be only a single image leak, which feels strange. Perhaps this is something else leaking, and it happens to only have one image in it? Solaris 2.6, current build as of tonight (May 26). gcc 2.7.2.3, etc. MLK: 3072 bytes leaked at 0x98b940 * This memory was allocated from: malloc [rtlib.o] __bUiLtIn_nEw [libgcc.a] __builtin_new [rtlib.o] __bUiLtIn_vEc_nEw [libgcc.a] __builtin_vec_new [rtlib.o] nsImageGTK::Init(int,int,int,nsMaskRequirements) [nsImageGTK.cpp:139] ImageRendererImpl::NewPixmap(void*,int,int,_NI_Pixmap*,_NI_Pixmap*) [nsImageRenderer.cpp:102] il_size(il_container_struct*) [if.cpp:782] ImgDCallbk::ImgDCBImageSize() [if.cpp:176] il_gif_write(il_container_struct*,const unsigned char*,int) [gif.cpp:1288] GIFDecoder::ImgDWrite(const unsigned char*,int) [nsGIFDecoder.cpp:274] IL_StreamWrite(il_container_struct*,const unsigned char*,int) [if.cpp:969] NetReaderImpl::Write(const unsigned char*,int) [ilNetReader.cpp:92] ImageConsumer::OnDataAvailable(nsIURL*,nsIInputStream*,unsigned int) [nsImageNetContextAsync.cpp:235] nsDocumentBindInfo::OnDataAvailable(nsIURL*,nsIInputStream*,unsigned int) [nsDocLoader.cpp:1502] stub_put_block(_NET_StreamClass*,const char*,int) [nsStubContext.cpp:834] net_read_file_chunk [mkfile.c:956] net_ProcessFile [mkfile.c:1327] NET_ProcessNet [mkgeturl.c:3355] NET_PollSockets [mkselect.c:298] nsNetlibService::NetPollSocketsCallback(nsITimer*,void*) [nsNetService.cpp:1276] TimerImpl::FireTimeout() [nsTimer.cpp:73] nsTimerExpired [nsTimer.cpp:189] g_timeout_dispatch [gmain.c:1147] g_main_dispatch [gmain.c:647] g_main_iterate [gmain.c:854] g_main_run [gmain.c:912] gtk_main [gtkmain.c:475] nsAppShell::Run() [nsAppShell.cpp:197] nsAppShellService::Run() [nsAppShellService.cpp:400]

Subsequent purify work has shown that more than just one image leaks in this manner. Not sure of the criteria for making it leak though yet.

I need more time. Gotta push it to M9. -pn

-> m10

Two leaks were found that could have contributed to this report. One was found in the doc loader. For every image, no doc loader was released. This was significant on animated gifs. There was another memleak in the timer. I don't know the details, but this would also affect image loading. Bruce, is there a place where I can see your recent purify logs? thanks, pn

Are we leaking with each frame of an animated GIF? If so... we'll be scared enough to make it a PDT+. Thanks,

Ran bloaty with viewer(throbbers turned off). opened res/samples/gear1.gif, an animated gif, for a few seconds. GIFDecoder: 12 bytes/instance and 204 bytes leaked total. While this is not leaking for each frame, I'd say the leak gets worse for each animation loop...which is bad enough to be a PDT+. just my 2 cents. ;->

I think it would be safe to make this a duplicate ofbug 15817, mem leak for each gif decoder instance. -pn *** This bug has been marked as a duplicate of 15817 ***

[code-level bug; rubber-stamping as duplicate.] Bruce-san, please feel free to re-open if this conclusion is erroneous.