Closed Bug 156540 Opened 22 years ago Closed 21 years ago

Crash opening MNG [@ !strncat ?] [@ read_chunk ?] [@ memmove]

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ariel_gonz, Assigned: tor)

References

(
URL
)

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(1 file)

Stack trace build 20021123 (CVS) on Linux
2.71 KB, text/plain
Details 
Build: 2002-07-09-13, Win2k

Also crashes 2002-06-17-12

File was made using pngcrush 1.5.9 using the -loco option. It appears to be a
different problem than Bug 153760. I don't have access to the talkback reports,
but according to Dr. Watson it appears to crash in in the strncat fuction.
Could you attach the file that causes the crash please?
Updated the URL pointing to the file.
The drwatson log is also available is needed.
Oh and sorry, forgot... here is the talkback ID:

TB8152157X

I had two more from the earlier build but lost them when I updated.
URL: http://expert.cc.purdue.edu/~ariel/lo...
->tor
Assignee: pavlov → tor
Severity: normal → critical
Keywords: crash, stackwanted
linux build 20020709 briefly displays an image and then says:
The file "..../loco.mng" cannot be displayed, because it contains errors.
Whiteboard: Need TB8152157X data
win98 build 2002082308, can't reproduce. (not the crash at least, I do get image
contains errors)

Ariel, are you still seeing this crash? If so, could you get another talkback
report?
I can reproduce this if I put the .mng url into a
html file
    <html><body>
    <img src="http://expert.cc.purdue.edu/~ariel/loco.mng">
    </body></html>

However in looking at this, there seems to be a bug with
VERY large mng images.  And am guessing it is fixed with
1.0.5 of mng.  I found a reference in the new libmng_read.c
B581625 - large chunks fail with suspension reads.
I am guessing this is it - but need to look into it
*** Bug 153760 has been marked as a duplicate of this bug. ***
I have verified that this crash will be fixed when
we land the MNG1.0.5 source at some point in the near
future.  However, I have also been told that the image,
loco.mng, "is using an invalid filter_method in the 
enclosed PNG".  So therefore while the crash won't 
happen, unless this MNG image is fixed, it probably 
WON'T be displayed when the new MNG source is landed.
Hi,

what size is to be considered as VERY large? I have here a 720k-mng which
sometimes gives me the error message, that it is broken, but more often crashes
the browser.

http://www.aei.mpg.de/~knarf/bugs/mozilla/156540/movie.mng

thanks, Frank
Thanks for the link!  I crashed and my incident report is  13546369  (Using win
XP branch build 2002110508)

   msvcrt.dll + 0x32ea0 (0x77c42ea0)    
     il_mng_readdata
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\mng\imgContainerMNG.cpp,
line 291]
     read_databuffer
[d:\builds\seamonkey\mozilla\modules\libimg\mng\libmng_read.c, line 153]
     read_chunk [d:\builds\seamonkey\mozilla\modules\libimg\mng\libmng_read.c,
line 546]
     read_graphic [d:\builds\seamonkey\mozilla\modules\libimg\mng\libmng_read.c,
line 668]
     mng_display_resume
[d:\builds\seamonkey\mozilla\modules\libimg\mng\libmng_hlapi.c, line 1479]
     il_mng_timeout_func
[d:\builds\seamonkey\mozilla\modules\libpr0n\decoders\mng\imgContainerMNG.cpp,
line 477]
     nsTimerImpl::Fire
[d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 345]
     nsAppShell::Run
[d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 156]
     nsAppShell::Run
[d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 156]
     nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 458]
     main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1492]
     main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1839]
     WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1857]
     WinMainCRTStartup()  
     kernel32.dll + 0x1eb69 (0x77e7eb69)  

Doesn't crash with an updated libmng, which will be landing as soon
as they finalize this version.

http://www.aei.mpg.de/~knarf/bugs/mozilla/156540/movie.mng Crashes Mac OS X
branch build 2002110505 and linux 2002110507, changing os to all
OS: Windows 2000 → All
Blocks: 155598
Keywords: stackwanted → testcase
Summary: Crash: Opening MNG (maybe @!strncat ?) → Crash: Opening MNG [@ !strncat ?] [@ read_chunk ?]
Whiteboard: Need TB8152157X data
If not a dupe, I guess the new libmng library will also fix bug 155598, stacks
are similar if not identical.
*** Bug 192205 has been marked as a duplicate of this bug. ***
*** Bug 181747 has been marked as a duplicate of this bug. ***
Setting Hardware=All and adding [@memmove] per comment 14.
Hardware: PC → All
Summary: Crash: Opening MNG [@ !strncat ?] [@ read_chunk ?] → Crash: Opening MNG [@ !strncat ?] [@ read_chunk ?] [@ memmove]
Adding dependency on bug 181676 per comment 8.
Depends on: 181676
Summary: Crash: Opening MNG [@ !strncat ?] [@ read_chunk ?] [@ memmove] → Crash opening MNG [@ !strncat ?] [@ read_chunk ?] [@ memmove]
tor: so can this bug be marked FIXED, now that the new libmng has landed?
I've verified that both images do what they're supposed to do on W2K / build
2003031004

loco.mng just displays an error-message now. It contains invalid filtertypes in
the embedded PNG's. The 'loco' option is an experimental 'feature' in IM and
*must not* be used for public MNG's!

The 720KB video.mng shows as designed, although I can't really say it looks good....
ok. marking FIXED.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 198591 has been marked as a duplicate of this bug. ***
NB: Bug 198591 was marked as a duplicate of this bug.  However, Bug 198591 still
exists even though this bug has been marked fixed.
Crash Signature: [@ !strncat ?] [@ read_chunk ?] [@ memmove]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: