Closed
Bug 7196
Opened 25 years ago
Closed 25 years ago
[DOGFOOD]MLK: 3072 bytes leaked- a single image leaking?
Categories
(Core :: Graphics: ImageLib, defect, P3)
Core
Graphics: ImageLib
Tracking
()
M11
People
(Reporter: bruce, Assigned: pnunn)
References
Details
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]
Reporter | ||
Comment 1•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
-> 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
Updated•25 years ago
|
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?
Updated•25 years ago
|
Whiteboard: [PDT-]
Updated•25 years ago
|
Whiteboard: [PDT-]
Comment 5•25 years ago
|
||
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: 25 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 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 8•25 years ago
|
||
[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.
Description
•