JNG images crash Mozilla on Windows[@ mng_add_chunk ]

RESOLVED FIXED

Status

()

Core
ImageLib
--
critical
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: Olivier Cahagne, Assigned: Glenn Randers-Pehrson)

Tracking

({crash, fixed1.4.2})

1.4 Branch
x86
Windows 2000
crash, fixed1.4.2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.4.1 -

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
build ID: 2003030908 on Win2k.

Steps to reproduce:
1. Load URL http://www.libmng.com/MNGsuite/anke_diff_img.html
2. Mozilla crashes.

Talkback ID: TB17913211K.
URL taken from bug 44866.
Perhaps a regression from new libmng 1.05, bug 181676 ?
(Reporter)

Updated

14 years ago
Whiteboard: TB17913211K

Comment 1

14 years ago
WFM with the same build (2003030908 on Win2k.)
(Reporter)

Comment 2

14 years ago
Created attachment 116755 [details]
MNG Image that crashes Mozilla
(Reporter)

Comment 3

14 years ago
Created attachment 116756 [details]
Second MNG image that crashes Mozilla

Comment 4

14 years ago
No crash for me with 20030309-1.3.

Comment 5

14 years ago
Created attachment 116767 [details]
Stack for Talkback 17913211
crash is in the mng library, cc'ing the author
crashing line is:
http://lxr.mozilla.org/seamonkey/source/modules/libimg/mng/libmng_chunk_prc.c#83
 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
(Reporter)

Updated

14 years ago
Summary: MNG Chromacity testcase crashes Mozilla → MNG Chromacity testcase crashes Mozilla [@ mng_add_chunk ]

Comment 7

14 years ago
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:

     mng_add_chunk
[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?

Comment 8

14 years ago
Gerard: didn't you say that you had reproduced this bug on your own machine?

Comment 9

14 years ago
Yep. Using the 2003031004 nightly. But that just gives me an access violation
(reading address 0).

Comment 10

14 years ago
Actualy not my own machine, but the one I'm using at work (Win2K).

Comment 11

14 years ago
Same machine. Different viewer: no problemo

Comment 12

14 years ago
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.  

Comment 13

14 years ago
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

Comment 14

14 years ago
> 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
P/J/MNG.

Comment 15

14 years ago
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)
        mng_add_chunk
and then in
    mng_add_chunk()
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. ***
(Assignee)

Comment 17

14 years ago
WFM
Moz 1.3 Gecko/20030312 Win 95 Glenn

Comment 18

14 years ago
Crashes for me using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b)
Gecko/20030501

Peace...

Comment 19

14 years ago
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
http://lxr.mozilla.org/seamonkey/source/modules/libimg/mng/libmng_chunk_io.c#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,
                                                         pRawdata);

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

Comment 20

14 years ago
Jim,

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

Gerard

Comment 21

14 years ago
Crashes for me on Windows XP Home using Mozilla 1.4 RC1
*** Bug 212051 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

14 years ago
Reassigning to myself.
Assignee: jdunn → randeg
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 24

14 years ago
Accepting bug.

Additional URLs, from bug #212051
http://pmt.sf.net/opossum/opossum.html
http://pmt.sf.net/opossum/opossum.jng

Question to those who see a crash:  Does
http://pmt.sf.net/opossum/opposum.mng
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 libmng.sf.net 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.
(Assignee)

Comment 25

14 years ago
I meant "current libmng-1.0.6"
(Assignee)

Comment 26

14 years ago
Marking as a blocker for 1.4.x and bug #18574
Blocks: 18574
Flags: blocking1.4.x+

Comment 27

14 years ago
Trying to view http://pmt.sf.net/opossum/ with Mozilla 1.4 on Windows XP Home
crashes Mozilla.
(Assignee)

Comment 28

14 years ago
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 ]

Comment 29

14 years ago
> 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+
(Assignee)

Comment 30

14 years ago
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?

Comment 31

14 years ago
Able to view http://pmt.sourceforge.net/opossum/ 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?
(Assignee)

Comment 32

14 years ago
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 http://pmt.sf.net in the "firebird-with-jng" package. You can
test it against sample JNG files in http://pmt.sf.net/opossum/index.html

WFM on Windows 95.   Enjoy. ../glennrp

Comment 33

14 years ago
When you've got a reviewed patch that's ready to land please request approval1.4?
(Assignee)

Comment 34

14 years ago
Created attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash
(Assignee)

Comment 35

14 years ago
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

r?
Attachment #129051 - Flags: review?
(Assignee)

Comment 36

14 years ago
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)
(Assignee)

Updated

14 years ago
Version: Trunk → 1.4 Branch

Updated

14 years ago
Flags: blocking1.4.1? → blocking1.4.1-

Comment 37

14 years ago
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+)
(Assignee)

Updated

14 years ago
Attachment #129051 - Flags: review?(pavlov) → review?(tor)

Updated

14 years ago
Attachment #129051 - Flags: review?(tor) → review+
(Assignee)

Comment 38

14 years ago
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 39

14 years ago
Comment on attachment 129051 [details] [diff] [review]
Patch to work around Microsoft compiler bug that causes JNG crash

sr=rbs
Attachment #129051 - Flags: superreview?(rbs) → superreview+
(Assignee)

Comment 40

14 years ago
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?

Comment 41

14 years ago
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.
(Assignee)

Comment 42

14 years ago
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 http://stud4.tuwien.ac.at/~e0225227/
(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.

Comment 44

14 years ago
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 http://stud4.tuwien.ac.at/~e0225227/ )

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. 

Comment 45

14 years ago
"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??

Comment 46

14 years ago
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
1.5.20030.17168.

Talkback ID: TB23957734Z
(Assignee)

Comment 47

14 years ago
Can someone provide the stack trace for  TB23957734Z ?
(Assignee)

Comment 48

14 years ago
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?
(Assignee)

Updated

14 years ago
Blocks: 188116

Updated

14 years ago
Flags: blocking1.4.2?

Comment 49

14 years ago
I've installed Mozilla 1.5 on my Windows ME and intalled the mng.xpi found at
http://stud4.tuwien.ac.at/~e0225227/.  Unfortunately it does not show the mng or
jng images found at http://pmt.sourceforge.net/opossum/.  How do we get mng
support back in the trunk?

Comment 50

14 years ago
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,
(http://mngzilla.sourceforge.net/) 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
Firebird/0.7+

Comment 51

14 years ago
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.

Comment 52

14 years ago
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.

http://forums.mozillazine.org/viewtopic.php?t=32282

Comment 53

14 years ago
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)
(Assignee)

Comment 54

14 years ago
Created attachment 134570 [details] [diff] [review]
Revised patch to work around MS compiler bug that crashes JNG

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
(Assignee)

Updated

14 years ago
Attachment #129051 - Flags: approval1.4.2?
(Assignee)

Comment 55

14 years ago
Re: comment #52, Nova's Firebird built for Windows 2000+ with MNG support and
JNG bugfix, is at https://sourceforge.net/project/showfiles.php?group_id=92539

Comment 56

14 years ago
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).
(Assignee)

Comment 57

14 years ago
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 58

14 years ago
Comment on attachment 134570 [details] [diff] [review]
Revised patch to work around MS compiler bug that crashes JNG

sr=rbs
Attachment #134570 - Flags: superreview?(rbs) → superreview+

Comment 59

14 years ago
@rbs:
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! 

Updated

14 years ago
Attachment #134570 - Flags: review?(tor) → review+
(Assignee)

Comment 60

14 years ago
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?

Comment 61

14 years ago
@rbs:

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

Comment 62

14 years ago
Try to ping the person who checked in the earlier patch. I don't keep old
branches around -- unless I am chasing something myself.

Comment 63

14 years ago
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?
Tor?

(Assignee)

Comment 64

14 years ago
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.

Comment 65

14 years ago
CC'ing Chris Hofmann (chosen randomly from the list of drivers).

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

14 years ago
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+

Comment 67

14 years ago
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))

Comment 68

14 years ago
@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.

Comment 69

14 years ago
Fix checked in to branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Keywords: fixed1.4.2

Updated

13 years ago
Flags: blocking1.4.2?

Comment 70

13 years ago
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
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.4.3/mozilla-1.4.3-source.tar.bz2.
Crash Signature: [@ mng_add_chunk ]
You need to log in before you can comment on or make changes to this bug.