Closed Bug 196670 Opened 17 years ago Closed 16 years ago

JNG images crash Mozilla on Windows[@ mng_add_chunk ]


(Core :: ImageLib, defect, critical)

1.4 Branch
Windows 2000
Not set





(Reporter: wolruf, Assigned: glennrp+bmo)




(Keywords: crash, fixed1.4.2)

Crash Data


(4 files, 1 obsolete file)

build ID: 2003030908 on Win2k.

Steps to reproduce:
1. Load URL
2. Mozilla crashes.

Talkback ID: TB17913211K.
URL taken from bug 44866.
Perhaps a regression from new libmng 1.05, bug 181676 ?
Whiteboard: TB17913211K
WFM with the same build (2003030908 on Win2k.)
No crash for me with 20030309-1.3.
crash is in the mng library, cc'ing the author
crashing line is:
 83     if (((mng_chunk_headerp)pChunk)->iChunkname == MNG_UINT_IHDR)

From the assembler & register output, I'd say pChunk is null.
Keywords: stackwanted
Whiteboard: TB17913211K
Summary: MNG Chromacity testcase crashes Mozilla → MNG Chromacity testcase crashes Mozilla [@ mng_add_chunk ]
That'd be amazing, since the only way (and from the trace the way that was
taken) to get there, is the following code:

  if (pChunk)                          /* store this chunk ? */
    mng_add_chunk (pData, pChunk);     /* do it */

So I'm hardpressed to understand how pChunk can be NULL.
The trace is a bit strange:

[c:/builds/seamonkey/mozilla/modules/libimg/mng/libmng_chunk_prc.c, line 83]
     read_chunk [c:/builds/seamonkey/mozilla/modules/libimg/mng/libmng_read.c,
line 564]
     read_chunk [c:/builds/seamonkey/mozilla/modules/libimg/mng/libmng_read.c,
line 564]

That second line should have been line 415 in process_raw_chunk in libmng_read.c
Which is the code listed above.

It doesn't add up. The bug can only be confirmed on W2K?
Gerard: didn't you say that you had reproduced this bug on your own machine?
Yep. Using the 2003031004 nightly. But that just gives me an access violation
(reading address 0).
Actualy not my own machine, but the one I'm using at work (Win2K).
Same machine. Different viewer: no problemo
I am seeing the crash on my win2k machine using a nightly
build but haven't been able to reproduce it using my own
build (I tried a debug and a non-opt build, am now building
an opt build to see if that shows the problem).

As for the stacktrace and pChunk, if memory is being overwritten
then who knows where it is crashing, since it usually wipes out
the stack and data...  This was the problem with the large mng's
causing a crash that the new mng library solved.  
Tor this looks like an issue with the new mng code.
Specifically I tracked it down to 

384 libmng_read.c
    iRetcode = pEntry->fRead (pData, pEntry, iBuflen, (mng_ptr)pBuf, &pChunk);

Well it is actually that pChunk is never set and
if we #define MNG_STORE_CHUNKS the crash doesn't occur.

Granted without this, pChunk should be null and all future checks
work... not sure why it is hosing... or if we should or should
NOT be defining MNG_STORE_CHUNKS, but this only occurs on OPTIMIZED
builds, so maybe the compiler is opting out some check... who knows.

But that stack gets horked... hard to step thru... I used printfs
> 384 libmng_read.c
>    iRetcode = pEntry->fRead (pData, pEntry, iBuflen, (mng_ptr)pBuf, &pChunk);

That's line 403 in my source and the one showing in the 'lxr SeaMonkey source'
online. Where's the 384 coming from?

Could you check what the value of 'iChunkname' is just before the failure. That
could help a bit for my search in the code.

MNG_STORE_CHUNKS should be off, unless you want to waste a lot of extra memory
during MNG playback. Keeping the chunks in memory isn't needed for displaying
ignore my line numbers (sorry for confusion), I have printfs all over
iChunkname  is 0x4a444154 when it crashes.

I am printing out pChunk right before (and after) the 
    if (pChunk)
and then in
and both print out 0x0

something is severely whacked... it is going into mng_add_chunk
even if pChunk==0 for this iChunkname
*** Bug 200314 has been marked as a duplicate of this bug. ***
Moz 1.3 Gecko/20030312 Win 95 Glenn
Crashes for me using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b)

I have traced this a bit further and have traced it to some
MS optimization issue in mng_read_jdat.  in libmng_chunk_io.c
if I put a printf("blah\n"); on line 5540

I no longer get a crash.  I have prepocessed this file/function
and here is the code (very straightforward, can't find anything wrong)
NOTE: it isn't going into the if bHas[J|D]HDR code either

  mng_retcode mng_read_jdat(mng_datap pData, mng_chunkp pHeader, 
                            mng_uint32 iRawlen, mng_uint8p pRawdata, 
                            mng_chunkp* ppChunk)
    if ((!pData->bHasJHDR) && (!pData->bHasDHDR)) { 
        mng_process_error(pData, (mng_retcode)1029, 0, 0); 
        return (mng_retcode)1029; 

    if (iRawlen == 0) { 
        mng_process_error (pData, (mng_retcode)1028, 0, 0); 
        return (mng_retcode)1028; 

    pData->bHasJDAT = 1;          

    if (iRawlen) {                                    
        mng_retcode iRetcode =  mng_process_display_jdat(pData, iRawlen,

        if (iRetcode)
            return iRetcode;
    return (mng_retcode)0;                  


Is there any way in VC to get the resulting assembler-code for that particular
piece of the source?

Crashes for me on Windows XP Home using Mozilla 1.4 RC1
*** Bug 212051 has been marked as a duplicate of this bug. ***
Reassigning to myself.
Assignee: jdunn → randeg
Accepting bug.

Additional URLs, from bug #212051

Question to those who see a crash:  Does
also crash?  The only difference is that it is wrapped in
MNG MHDR/MEND chunks while the *.jng is a standalone JNG file.

Also, does building Mozilla-1.4 with the current libmng-2.0.6
in CVS at fix the problem?  I changed the handling
of the iRawlen variable which was being checked twice for equality
to zero (as you can see in comment #19), to avoid the double test in case
that was what was confusing the VC optimizing compiler.

Note, any testing has to be done with Mozilla-1.4 as the basis,
since MNG is currently off the trunk.
I meant "current libmng-1.0.6"
Marking as a blocker for 1.4.x and bug #18574
Blocks: mng
Flags: blocking1.4.x+
Trying to view with Mozilla 1.4 on Windows XP Home
crashes Mozilla.
I believe that this problem was fixed in libmng-1.0.6 on June 2.
However, since there are many changes in libmng-1.0.6 related to
reduction of the footprint for Mozilla-1.5, here is the 2-line change
required merely to fix this bug:

Delete lines 5491 and 5547 from libmng_chunk_io.c in mozilla-1.4.
Both of them are "if (iRawlen)".

Since the crash really has nothing to do with chromaticity, I'm changing
the summary to be a more accurate reflection of the problem.
Summary: MNG Chromacity testcase crashes Mozilla [@ mng_add_chunk ] → JNG images crash Mozilla on Windows[@ mng_add_chunk ]
> Marking as a blocker for 1.4.x and bug #18574

Glenn: only Mozilla drivers can set (+) blocking flags.  you can nominate (?)
the bug and drivers will consider it.
Flags: blocking1.4.x+
Sorry for overstepping authority.  Nominating as 1.4.x blocker, in hopes that
someone will test the simple 2-line fix.
Flags: blocking1.4.x?
Able to view using Mozilla 1.4 on Windows ME
without crashing.  I can see both the mng and jng files fine.  Why does it crash
on Windows XP Home but not on Windows ME?
aebrahim kindly built version 2003-0603 (the last version before MNG/JNG support
was removed), applying my bugfix posted in comment #28. You can get it from the
download area at in the "firebird-with-jng" package. You can
test it against sample JNG files in

WFM on Windows 95.   Enjoy. ../glennrp
When you've got a reviewed patch that's ready to land please request approval1.4?
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

Attachment #129051 - Flags: review?
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

pav: r?
Attachment #129051 - Flags: review? → review?(pavlov)
Version: Trunk → 1.4 Branch
Flags: blocking1.4.1? → blocking1.4.1-
Are there any plans to also fix this bug with the post-1.4 Mozilla MNG-support
XPI? I know it's a 3rd-party XPI.. but the crash happens there as well,
currently. (Tested using Mozilla Firebird - Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.5b) Gecko/20030822 Mozilla Firebird/0.6.1+)
Attachment #129051 - Flags: review?(pavlov) → review?(tor)
Attachment #129051 - Flags: review?(tor) → review+
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

rbs: sr?

This simple patch removes two redundant lines of code.	The Microsoft compiler
discovers the redundancy but produces bad code when it tries to remove it.  See
comment #19 and comment #28 for identification of the bug and comment #32 for a
test executable.
Attachment #129051 - Flags: superreview?(rbs)
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

Attachment #129051 - Flags: superreview?(rbs) → superreview+
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

approval 1.4.x?
Attachment #129051 - Flags: approval1.4.2?
Attachment #129051 - Flags: approval1.4.1?
could cbiesinger update the ming xpi for firebird as well??
who can ask him?

the jng crashing behaviour occurs with recent firebird nightlies as well if the
xpi is installed.
I wrote cb a few days ago about this, but apparently he's not in a position
to redo the Windows XPI right now.
an updated mozilla mng xpi is now available at
(created by getting the latest libmng from cvs and copying all *.c *.h files
over the old ones, and then recompiling)

it doesn't crash on the url mentioned in this bug.
hmm. maybe I'am a little bit stupid, but...

I run the official RC of firebird 0.7 and installed the new mng.xpi mentioned
above (Version 1.0.6-1 from )

Now when I try to click on the jng examples on the top of this page, firebird
still crashes.

And firebird gave me the missing mozz.dll error again, so I had to work around
thos problem by adding mozz.dll manually. 
"normal" mng images are displayed correctly, so the xpi is installed properly.

but both jng testcases on the top crash my firebird.

who is using firebird on winXP and can confirm that the problem persists??
The problem does still persist.. (Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.5b) Gecko/20030826 Mozilla Firebird/0.6.1+)... Installation of the
XPI was successful, on a fresh install of Firebird.. (I.E. The old XPI is gone
first..).. It requires mozz.dll to function and install properly, it seems..
after that, it works as the one (1.0.5-1) did.. the crash still appears. at the
URL in this bug. Not sure this matters, but the mozz.dll version I used was

Talkback ID: TB23957734Z
Can someone provide the stack trace for  TB23957734Z ?
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

approval 1.4.2?
Attachment #129051 - Flags: approval1.4.1?
Blocks: 188116
Flags: blocking1.4.2?
I've installed Mozilla 1.5 on my Windows ME and intalled the mng.xpi found at  Unfortunately it does not show the mng or
jng images found at  How do we get mng
support back in the trunk?
I've been figuring how to build my own MNG-capable Firebird build.  Got one
working just now, and it works with MNG but is affected by this same bug on JNGs.

I manually applied patching as per the MNGZilla site,
( but did it by hand instead of a copy over or
using the patches.  (Manually went through the entire reversal patch and
modified it to newer information.)  Using libmng 1.0.6.  Can confirm the crash
was in imgmng.dll.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031029
Congratulations for succeeding in building a mng-firebird. The same crash
happens when installing the xpi, as I mentioned before. Can you provide a stack
trace (as I don't use a talkback build)? That would help Glenn a lot.
Glenn, your test fix to file libmng_chunk_io.c (that you emailed me) worked in
my latest MNG-enabled Firebird build.  My latest build doesn't crash on JNG images.
WFM :))

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030
Firebird/0.7+ (Mike Tigas (Nova); MNG; Ox,G6)
Here is a more robust patch that has been shown to work with VC7.0.  The change
is still pretty simple but now involves a dozen lines instead of just two.
Attachment #129051 - Attachment is obsolete: true
Attachment #129051 - Flags: approval1.4.2?
Re: comment #52, Nova's Firebird built for Windows 2000+ with MNG support and
JNG bugfix, is at
hmm, Glenn please set a review/superreview flag again. perhaps this can be
driven into 1.4.x at some time.

Hopefully christian biesinger can update his xpi again to finally cover the
crash bug with firebird (and maybe include the missing moz.dll).
Comment on attachment 134570 [details] [diff] [review]
Revised patch to work around MS compiler bug that crashes JNG

tor: r? rbs: sr?  The new patch provides a much more robust workaround to the
Microsoft compiler bug.
Attachment #134570 - Flags: superreview?(rbs)
Attachment #134570 - Flags: review?(tor)
Comment on attachment 134570 [details] [diff] [review]
Revised patch to work around MS compiler bug that crashes JNG

Attachment #134570 - Flags: superreview?(rbs) → superreview+
as glenn has not sufficient rights to check it into the 1.4 branch himself, can
you do that? so this bug can be finally marked fixed! 
Attachment #134570 - Flags: review?(tor) → review+
Comment on attachment 134570 [details] [diff] [review]
Revised patch to work around MS compiler bug that crashes JNG

approval 1.4.2?
Attachment #134570 - Flags: approval1.4.2?

sorry to bother again. but can you check this patch into the branch. as 1.4.2 is
a stability orientated release and this is a big crasher bug in it. Glenn hasn't
enough rights to do this by himself.

And sorry for adding you to the CC list. I don't know if this is "proper
behaviour" in bugzilla. But with your help this bug could finally be closed.

Tnx, Bernd
Try to ping the person who checked in the earlier patch. I don't keep old
branches around -- unless I am chasing something myself.
Thanks rbs for the comment. But as far as I understand the previous patch wasn't
checked in at all (or am I missing something?).

Maybe Tor can check in the patch?

The first patch got r/sr but was never checked in.  The second patch
obsoleted the first.  So all that needs to be done is to check in the
"revised" patch, assuming it's approved for 1.4.2.
CC'ing Chris Hofmann (chosen randomly from the list of drivers).

I don't really want to spam bugzilla, but I want to prevent this bug falling off
the radar again (I'm not using the 1.4 branch by myself).

Maybe he can help to check this crash bug in.
Comment on attachment 134570 [details] [diff] [review]
Revised patch to work around MS compiler bug that crashes JNG

a=mkaply since it is a crasher
Attachment #134570 - Flags: approval1.4.2? → approval1.4.2+
Glenn, did you get Christian Biesinger to update the xpi? (it would nice, if he
could test the xpi with firebird, so that no file copying/registering is needed))
@Michael Kaply

Can you check the patch into the branch?

Glenn doesn't have the appropriate rights to do so.

So that we can mark this bug fixed.
Fix checked in to branch.
Closed: 16 years ago
Resolution: --- → FIXED
Keywords: fixed1.4.2
Flags: blocking1.4.2?
JNG images crash Mozilla on Windows again with Mozilla 1.4.3 :-(

I compiled Mozilla 1.4.3 with MS Visual C++ 6.0 SP 5 prof. + Processor Pack and
options "--enable-default-toolkit=windows --disable-tests --disable-debug
--enable-optimize --without-system-nspr --without-system-zlib
--without-system-jpeg --without-system-png --without-system-mng --enable-crypto
--disable-composer --disable-chatzilla --disable-mailnews
--enable-extensions=default,-irc --disable-ldap --enable-strip".

On Microsoft Windows XP [Version 5.1.2600] Mozilla continuously crashes whithout
any messages when visiting a website with JNG images.

Source was
Crash Signature: [@ mng_add_chunk ]
You need to log in before you can comment on or make changes to this bug.