Closed Bug 32480 Opened 25 years ago Closed 25 years ago

Crash in IMG3250.DLL when accessing any site

Categories

(SeaMonkey :: General, defect, P3)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jay, Assigned: morse)

References

()

Details

(Keywords: smoketest)

From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (Win98; U) BuildID: 31915 Crashes when accessing any URL and attempting to load the first image. Crashes in IMG3250.DLL Reproducible: Always Steps to Reproduce: 1.Access any site 2. 3. Actual Results: Crashes in IMG3250.DLL upon accesss Expected Results: No crash
smoketest blocker
Severity: major → blocker
Keywords: smoketest
From SolarisX86: Bug also happens with clean profile...deleted Users50 directory and then tried...same crash. Also went into profile manager and deleted default and added a new fresh default...crashed same place again on startup.
this is killing the win32 builds. please help!
Assignee: cbegle → morse
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 32487 has been marked as a duplicate of this bug. ***
*** Bug 32487 has been marked as a duplicate of this bug. ***
Wow, I was behind by 7 reports! :) Please refer to bug 32487 (a duplicate I posted) for additional information helpful to this.
I don't experience any problems on Linux build 2000-03-19-09.
OK, I'm looking at it. I did change some code that has to do with fetching images so I could be the culprit. However I am unable to reproduce with a tree that I pulled on Saturday morning into which I added my changes. So I'm pulling and building a new tree right now and will try it. Should be done with the build by 11 AM and can start investigating it then. If anyone has a tree ready before then and would like to help out, contact me and I'll tell you what to look for.
Status: NEW → ASSIGNED
My linux CVS build works fine until I open a page with images. I believe I'm experiencing this same bug.
BTW, my build is NT.
If anybody is ready with a build, here is a test you can make to determine if it's my coding change that caused the problem. Simply add "return PR_TRUE" as the very firsts statment in the il_PermitLoad function in modules/libimg/if.cpp.
Making the change morse suggested fixes my crashing problems. It ignores my selective loading of image prefs now though.
changing platform/os to all since I see this on Mac as well.
Keywords: crash
OS: Windows 98 → All
Hardware: PC → All
Steve, how did you get past the precheckin tests? If you'd be so kind as to checkin your patch so we can respin and get more testing done, i'd appreciate it.
So I guess I am the culprit after all. My build is still not finished yet so could you try one more change. Apply these diffs to if.cpp. Thanks. Index: if.cpp =================================================================== RCS file: /cvsroot/mozilla/modules/libimg/src/if.cpp,v retrieving revision 3.46 diff -c -r3.46 if.cpp *** if.cpp 2000/03/19 16:57:46 3.46 --- if.cpp 2000/03/20 18:22:56 *************** *** 1913,1918 **** --- 1913,1919 ---- return PR_TRUE; } + #ifdef xxx /* real ugly hack until I figure out the right way to get the presContext from aObserver */ nsIPresContext* presContext = (nsIPresContext*)(((PRInt32 *)aObserver)[3]); *************** *** 1930,1935 **** --- 1931,1939 ---- Recycle(host); return PR_TRUE; } + #else + char* firstHost = PL_strdup(host); + #endif /* check to see if we need to block image from loading */ NS_WITH_SERVICE(nsICookieService, cookieservice, kCookieServiceCID, &rv);
Keywords: crash
OS: All → Windows 98
Hardware: All → PC
I got this past the pre-checkin test because it worked (and still does work) fine for me. I don't know why. I can't check in the patch because I haven't finished my build yet so I can't even compile it. But if someone who does have a build finished and can verify that the patch posted above fixes the problem, then please do check it in. My build won't finish for at least another half an hour.
I am not seeing the crash on a linux build from this morning 2000-03-20 with either an existing profile or a new profile. I have tried pages with images. My NT build from today is still building.
Morse, applied your second fix and rebuilt after clobbering modules/libimg. Everything seems to be working fine now.
I think I can explain why some people are seeing this and others on the identical platform are not. I put in a very bad hack (which was only temporary) that I now realize is probably very compiler dependent. I am compiling on winnt with vc6. The hack was probably customized for that compiler. The patch that I'm about to put in (as soon as my build finishes) will completely remove the hack and I'll keep it removed until I figure out the correct way to do what I was trying to accomplish.
My build is still not yet finished, but based on the comment from dan@ss-i.com I am checking in the patch. Trusting him that it compiled successfully because I am not even up to that step.
Fixed. Tested by dan@ss-i.com
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 32514 has been marked as a duplicate of this bug. ***
This is still occuring on todays commercial trunk Linux build 2000-03-20-09. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Jan, did you pick up my fix from 10:43 this morning?
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Still not fixed in 2000032009, same crash in IMG3250.DLL
Look, can people _please_ stop testing 2000032009! We know it doesn't work. It's 2000032011 you want, available now from: http://ftp.mozilla.org/pub/mozilla/nightly/2000-03-20-11-M15/ Gerv
*** Bug 32526 has been marked as a duplicate of this bug. ***
Verified Fixed with windows build (under NT with 032011 build). Was this XP? COmments below suggested it was but OS says win98. Changing OS to ALL. Can someone verify on Mac and Linux.
OS: Windows 98 → All
*** Bug 32511 has been marked as a duplicate of this bug. ***
in bug 32511 fenella@netscape.com verified that mac commercial 032011 is working. Need linux verification to Verify this one out.
*** Bug 32517 has been marked as a duplicate of this bug. ***
Fixed on linux CVS build (2000-03-21). Marking VERIFIED.
Status: RESOLVED → VERIFIED
Woo-Hoo! Thanks for all of the help on this one :)
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.