Closed
Bug 337402
Opened 18 years ago
Closed 18 years ago
When new page is opened to display single image, Camino crashes
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 337259
People
(Reporter: craig, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/418 (KHTML, like Gecko) Safari/417.9.2 Build Identifier: Browsing to a web page that has a link that opens a new window to display a single image causes the browser to crash. Reproducible: Always Steps to Reproduce: 1. Browse to 'http://www.versiontracker.com/dyn/moreinfo/macosx/28750' 2. Click on the screen shot to open it in a new window Actual Results: Camino crashes. Expected Results: The image should have appeared in a new window This bug is happening with the nightly build of Camino built on the 9th May. It does not happen in the 1.0.1 release build. Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 libSystem.B.dylib 0x90002f48 strlen + 8 1 org.mozilla.camino 0x003fe32c nsGlobalWindow::BuildURIfromBase(char const*, nsIURI**, int*, JSContext**) + 712 2 org.mozilla.camino 0x003fc718 nsGlobalWindow::OpenInternal(nsAString_internal const&, nsAString_internal const&, nsAString_internal const&, int, int, int, long*, unsigned, nsISupports*, nsIDOMWindow**) + 2060 3 org.mozilla.camino 0x003f7e44 nsGlobalWindow::Open(nsAString_internal const&, nsAString_internal const&, nsAString_internal const&, nsIDOMWindow**) + 48 4 org.mozilla.camino 0x0023a3e8 nsDocShell::InternalLoad(nsIURI*, nsIURI*, nsISupports*, unsigned, unsigned short const*, char const*, nsIInputStream*, nsIInputStream*, unsigned, nsISHEntry*, int, nsIDocShell**, nsIRequest**) + 1492 5 org.mozilla.camino 0x00214408 nsWebShell::OnLinkClickSync(nsIContent*, nsLinkVerb, nsIURI*, unsigned short const*, nsIInputStream*, nsIInputStream*, nsIDocShell**, nsIRequest**) + 1176 6 org.mozilla.camino 0x00213b94 non-virtual thunk [nv:-460] to nsWebShell::SetRendering(int) + 208 7 libxpcom_core.dylib 0x2c047298 PL_HandleEvent + 36 8 libxpcom_core.dylib 0x2c0471bc PL_ProcessPendingEvents + 128 9 com.apple.CoreFoundation 0x907e4a68 __CFRunLoopDoSources0 + 384 10 com.apple.CoreFoundation 0x907e3f98 __CFRunLoopRun + 452 11 com.apple.CoreFoundation 0x907e3a18 CFRunLoopRunSpecific + 268 12 com.apple.HIToolbox 0x9321c980 RunCurrentEventLoopInMode + 264 13 com.apple.HIToolbox 0x9321bf8c ReceiveNextEventCommon + 244 14 com.apple.HIToolbox 0x9321be80 BlockUntilNextEventMatchingListInMode + 96 15 com.apple.AppKit 0x9371e104 _DPSNextEvent + 384 16 com.apple.AppKit 0x9371ddc8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116 17 com.apple.AppKit 0x9371a30c -[NSApplication run] + 472 18 com.apple.AppKit 0x9380ae68 NSApplicationMain + 452 19 org.mozilla.camino 0x00008810 start + 432 20 org.mozilla.camino 0x00008690 start + 48 Thread 1: 0 libSystem.B.dylib 0x9001f5ec select + 12 1 libnspr4.dylib 0x2001f0f4 poll + 392 2 libnspr4.dylib 0x2001b8a8 PR_OpenDir + 944 3 org.mozilla.camino 0x000dde98 nsSocketTransportService::Poll(unsigned*) + 116 4 org.mozilla.camino 0x000de5e4 nsSocketTransportService::Run() + 432 5 libxpcom_core.dylib 0x2c049de8 nsThread::Main(void*) + 56 6 libnspr4.dylib 0x2001cd34 PR_Select + 852 7 libSystem.B.dylib 0x9002ba68 _pthread_body + 96 Thread 2: 0 libSystem.B.dylib 0x90054fc8 semaphore_timedwait_signal_trap + 8 1 libSystem.B.dylib 0x90054e24 pthread_cond_timedwait + 676 2 libnspr4.dylib 0x20017c1c PR_Unlock + 300 3 libnspr4.dylib 0x20017e80 PR_WaitCondVar + 136 4 libxpcom_core.dylib 0x2c04c9d0 TimerThread::Run() + 412 5 libxpcom_core.dylib 0x2c049de8 nsThread::Main(void*) + 56 6 libnspr4.dylib 0x2001cd34 PR_Select + 852 7 libSystem.B.dylib 0x9002ba68 _pthread_body + 96 Thread 3: 0 libSystem.B.dylib 0x90054fc8 semaphore_timedwait_signal_trap + 8 1 libSystem.B.dylib 0x90054e24 pthread_cond_timedwait + 676 2 libnspr4.dylib 0x20017c1c PR_Unlock + 300 3 libnspr4.dylib 0x20017e80 PR_WaitCondVar + 136 4 org.mozilla.camino 0x0009b550 nsIOThreadPool::ThreadFunc(void*) + 116 5 libnspr4.dylib 0x2001cd34 PR_Select + 852 6 libSystem.B.dylib 0x9002ba68 _pthread_body + 96 Thread 4: 0 libSystem.B.dylib 0x9001f5ec select + 12 1 com.apple.CoreFoundation 0x907f69a8 __CFSocketManager + 472 2 libSystem.B.dylib 0x9002ba68 _pthread_body + 96 Thread 5: 0 libSystem.B.dylib 0x90054fc8 semaphore_timedwait_signal_trap + 8 1 libSystem.B.dylib 0x90054e24 pthread_cond_timedwait + 676 2 libnspr4.dylib 0x20017c1c PR_Unlock + 300 3 libnspr4.dylib 0x20017e80 PR_WaitCondVar + 136 4 org.mozilla.camino 0x000ea8a8 nsHostResolver::GetHostToLookup(nsHostRecord**) + 132 5 org.mozilla.camino 0x000eabfc nsHostResolver::ThreadFunc(void*) + 184 6 libnspr4.dylib 0x2001cd34 PR_Select + 852 7 libSystem.B.dylib 0x9002ba68 _pthread_body + 96 Thread 6: 0 libSystem.B.dylib 0x9002c128 semaphore_wait_signal_trap + 8 1 libSystem.B.dylib 0x90030bec pthread_cond_wait + 480 2 com.apple.Foundation 0x9297c300 -[NSConditionLock lockWhenCondition:] + 68 3 com.apple.AppKit 0x937bad2c -[NSUIHeartBeat _heartBeatThread:] + 324 4 com.apple.Foundation 0x92975194 forkThreadForFunction + 108 5 libSystem.B.dylib 0x9002ba68 _pthread_body + 96 Thread 7: 0 libSystem.B.dylib 0x90054fc8 semaphore_timedwait_signal_trap + 8 1 libSystem.B.dylib 0x90071648 pthread_cond_timedwait_relative_np + 556 2 ...apple.AddressBook.framework 0x9495a704 -[ABMetaDataController workLoop] + 200 3 com.apple.Foundation 0x92975194 forkThreadForFunction + 108 4 libSystem.B.dylib 0x9002ba68 _pthread_body + 96
Please file bugs with the build you used when seeing the buggy behavior (especially now, since we have nightly builds generated on 3 branches), and please attach crash logs (using the Create a New Attachment link after filing) rather than pasting inline; thanks! Luckily, I happen to know which build and which crash you're talking about ;) *** This bug has been marked as a duplicate of 337259 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
|
Reporter | |
Comment 2•18 years ago
|
||
(In reply to comment #1) > Please file bugs with the build you used when seeing the buggy behavior > (especially now, since we have nightly builds generated on 3 branches), Sorry, my bad. I'm a bugzilla virgin. I didn't notice where to select what build of Camino I am running. I tried noting the build date in the notes field of the bug. Please let me know where I should fill in the build date. > please attach crash logs (using the Create a New Attachment link after filing) > rather than pasting inline; thanks! Great. Ok, will do. I did read that, but I thought the crash log I sent was small enough. I will not paste any logs inline. > > Luckily, I happen to know which build and which crash you're talking about ;) Great. I'm really enjoying Camino and can't code in Objective-C (I'm Java only), so filing bugs is my impotent way of helping! Keep up the good work.
(In reply to comment #2) > (In reply to comment #1) > > Please file bugs with the build you used when seeing the buggy behavior > > (especially now, since we have nightly builds generated on 3 branches), > > Sorry, my bad. I'm a bugzilla virgin. I didn't notice where to select what > build of Camino I am running. I tried noting the build date in the notes field > of the bug. > Please let me know where I should fill in the build date. This is captured automatically by the bug-reporting form from the browser and reported as the first 2 (or 4, depending on wrapping) lines of your initial report (aka comment 0). In other words, if you crash using Camino 200600509 (1.0+), report the bug using that build (if at all possible) and the bug-reporting form will automatically include that info. (When you can't report the bug using the actual build, say if it crashes on every page, pasting the string from the About Camino window manually into the report comments is the best way of providing us the pieces of info we need.) ...Unless you've been using User-Agent spoofing (via CamiTools or the hidden pref in user.js) to pretend to be another browser, which it looks like you may have been doing. If you do spoof your user-agent for some reason, always check the site with the spoofing disabled (and report the bug here with the spoofing disabled), since many sites send different code to different browsers depending on those browsers' features and bugs, so having Camino claim to be, say, Safari, will cause some sites to send code tailored to Safari's bugs, which won't work in Camino because Camino doesn't have those bugs (Gecko has other bugs, to be sure). No worries; thanks for using Camino and reporting bugs :)
|
|
Reporter | |
Comment 4•18 years ago
|
||
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Please file bugs with the build you used when seeing the buggy behavior > > > (especially now, since we have nightly builds generated on 3 branches), > > > > Sorry, my bad. I'm a bugzilla virgin. I didn't notice where to select what > > build of Camino I am running. I tried noting the build date in the notes field > > of the bug. > > Please let me know where I should fill in the build date. > > This is captured automatically by the bug-reporting form from the browser and > reported as the first 2 (or 4, depending on wrapping) lines of your initial > report (aka comment 0). In other words, if you crash using Camino 200600509 > (1.0+), report the bug using that build (if at all possible) and the > bug-reporting form will automatically include that info. (When you can't > report the bug using the actual build, say if it crashes on every page, pasting > the string from the About Camino window manually into the report comments is > the best way of providing us the pieces of info we need.) > > ...Unless you've been using User-Agent spoofing (via CamiTools or the hidden > pref in user.js) to pretend to be another browser, which it looks like you may > have been doing. If you do spoof your user-agent for some reason, always check > the site with the spoofing disabled (and report the bug here with the spoofing > disabled), since many sites send different code to different browsers depending > on those browsers' features and bugs, so having Camino claim to be, say, > Safari, will cause some sites to send code tailored to Safari's bugs, which > won't work in Camino because Camino doesn't have those bugs (Gecko has other > bugs, to be sure). > > No worries; thanks for using Camino and reporting bugs :) > I fully understand. I submitted the bug using Safari, but I know now that I should do it with Camino to get the user agent info. Thanks chaps. Camino rocks.
|
||
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•