7196 - [DOGFOOD]MLK: 3072 bytes leaked- a single image leaking?

Status: VERIFIED DUPLICATE of bug 15817

(Core :: Graphics: ImageLib, defect, P3)

Description

[Bruce Mitchener]

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]

Comment 1

[Bruce Mitchener]

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 2

[pnunn]

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

Comment 3

[chris hofmann]

-> m10

Comment 4

[pnunn]

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

Comment 5

[Jim Roskind]

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

Comment 6

[pnunn]

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. ;->

Comment 7

[pnunn]

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 ***

Comment 8

[Eli Goldberg]

[code-level bug; rubber-stamping as duplicate.]

Bruce-san, please feel free to re-open if this conclusion is erroneous.