Closed Bug 7196 Opened 21 years ago Closed 20 years ago
[DOGFOOD]MLK: 3072 bytes leaked- a single image leaking?
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 22.214.171.124, 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
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
Summary: MLK: a single image leaking? → MLK: 3072 bytes leaked- a single image leaking?
Summary: MLK: 3072 bytes leaked- a single image leaking? → [DOGFOOD]MLK: 3072 bytes leaked- a single image leaking?
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. ;->
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
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.
You need to log in before you can comment on or make changes to this bug.