Closed Bug 196670 Opened 22 years ago Closed 22 years ago

JNG images crash Mozilla on Windows[@ mng_add_chunk ]

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
1.4 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: wolruf, Assigned: glennrp+bmo)

References

(
URL
)

Details

(Keywords: crash, fixed1.4.2)

Crash Data

Attachments

(4 files, 1 obsolete file)

MNG Image that crashes Mozilla
23.70 KB, video/x-mng
Details
Second MNG image that crashes Mozilla
17.60 KB, video/x-mng
Details
Stack for Talkback 17913211
2.88 KB, text/plain
Details
Revised patch to work around MS compiler bug that crashes JNG
2.81 KB, patch
tor
: review+
rbs
: superreview+
mkaply
: approval1.4.2+
Details | Diff | Splinter Review
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 ?
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: 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
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: 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?
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 P/J/MNG.
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. ***
WFM Moz 1.3 Gecko/20030312 Win 95 Glenn
Crashes for me using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030501 Peace...
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; }
Jim, Is there any way in VC to get the resulting assembler-code for that particular piece of the source? Gerard
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
Status: NEW → ASSIGNED
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.
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 http://pmt.sf.net/opossum/ 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 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?
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
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 r?
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 sr=rbs
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 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.
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.
"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 1.5.20030.17168. 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 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?
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+
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. http://forums.mozillazine.org/viewtopic.php?t=32282
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 https://sourceforge.net/project/showfiles.php?group_id=92539
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 sr=rbs
Attachment #134570 - Flags: superreview?(rbs) → superreview+
@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!
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?
@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
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? Tor?
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). *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 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.
Status: ASSIGNED → RESOLVED
Closed: 22 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 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.

Attachment

General

Creator:
Created:
Updated:
Size: