425225 - Selecting an item from a <select> while page is loading can cause crash

Status: RESOLVED FIXED

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: User's crash log

As reported on the forum, selecting an item from a <select> while the page is still loading can cause a crash.

Comment 1

[Stuart Morgan]

Attachment: fix

We weren't always getting the right event by the time the asynchronous code fired, so this stores the event that actually triggers the menu.

Comment 2

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 311839 [details] [diff] [review]
fix

sr=pink

Comment 3

[Chris Lawson (gone)]

I'm about 99% sure that I've hit this twice in the past two days, but I have a *totally* different stack. Here's the top of the latest example:

Process:         Camino [8880]
Path:            /Applications/Internet/Camino Official Nightlies/Trunk/Camino.app/Contents/MacOS/Camino
Identifier:      org.mozilla.camino
Version:         2.0a1pre (2008.03.25)
Code Type:       PPC (Native)
Parent Process:  launchd [133]

Date/Time:       2008-03-26 21:04:17.284 -0500
OS Version:      Mac OS X 10.5.2 (9C7010)
Report Version:  6

Exception Type:  EXC_CRASH (SIGBUS)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  1

Thread 0:
0   libSystem.B.dylib             	0x958e9cb8 __kill + 12
1   talkback.dylib                	0x02756e2c FCProcessSignal(int, UNIX_EXCEPTION_CONTEXT*) + 196
2   talkback.dylib                	0x027594f0 fcStackDumpCollectorCreator(unsigned long, char*, int, char**) + 356
3   libSystem.B.dylib             	0x958e7bc0 _sigtramp + 64
4   ...ple.CoreServices.CarbonCore	0x95313f50 PBGetCatalogInfoSync + 640

Thread 1 Crashed:
0   libSystem.B.dylib             	0x958b1310 select$DARWIN_EXTSN$NOCANCEL + 8
1   libSystem.B.dylib             	0x9590754c select + 68
2   libnspr4.dylib                	0x01012c1c poll + 444
3   libnspr4.dylib                	0x0100ec6c PR_Poll + 908
4   org.mozilla.camino            	0x000e137c nsSocketTransportService::Poll(int, unsigned int*) + 204
5   org.mozilla.camino            	0x000e19ec nsSocketTransportService::DoPollIteration(int) + 524
6   org.mozilla.camino            	0x000e1c98 nsSocketTransportService::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) + 120
7   libxpcom_core.dylib           	0x00f59234 nsThread::ProcessNextEvent(int, int*) + 276
8   libxpcom_core.dylib           	0x00f148f8 NS_ProcessNextEvent_P(nsIThread*, int) + 72
9   org.mozilla.camino            	0x000e2450 nsSocketTransportService::Run() + 176
10  libxpcom_core.dylib           	0x00f592b4 nsThread::ProcessNextEvent(int, int*) + 404
11  libxpcom_core.dylib           	0x00f148f8 NS_ProcessNextEvent_P(nsIThread*, int) + 72
12  libxpcom_core.dylib           	0x00f5960c nsThread::ThreadFunc(void*) + 156
13  libnspr4.dylib                	0x0101045c _pt_root + 220
14  libSystem.B.dylib             	0x958a9b98 _pthread_start + 316

Thread 2:
0   libSystem.B.dylib             	0x958679f8 semaphore_timedwait_signal_trap + 8
1   libSystem.B.dylib             	0x958aae3c _pthread_cond_wait + 1320
2   libnspr4.dylib                	0x0100a5a4 pt_TimedWait + 164
3   libnspr4.dylib                	0x0100aa6c PR_WaitCondVar + 156
4   libxpcom_core.dylib           	0x00f5d7dc TimerThread::Run() + 348
5   libxpcom_core.dylib           	0x00f592b4 nsThread::ProcessNextEvent(int, int*) + 404
6   libxpcom_core.dylib           	0x00f148f8 NS_ProcessNextEvent_P(nsIThread*, int) + 72
7   libxpcom_core.dylib           	0x00f5960c nsThread::ThreadFunc(void*) + 156
8   libnspr4.dylib                	0x0101045c _pt_root + 220
9   libSystem.B.dylib             	0x958a9b98 _pthread_start + 316

Anyone have any ideas why this is so...wrong?

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is going to be pretty ugly, 9 of 19 Talkbacks so far (if Talkback's stacks can be believed). :(

I've run 1.6b3 from the time it finished building until now and never saw this, but apparently I don't use selects the same way others do :(

Comment 6

[Stuart Morgan]

If it's this bad, we could do an immediate b4 tomorrow. Maybe our odd-numbered betas are just cursed :P

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Over night, the number of crashes doubled, but the number of crashes specifically attributable to this bug only went up by 2.

The random hex crashes made up almost the entire set of new bugs, but about half of those have only the first frame, and the other half look like TB43132810x, which could be this crash, just missing the Camino frame.  Given that the stacks that *do* finger this bug (like TB43137930x) look entirely bizarre, it seems entirely possible that the other stacks just dropped the offending frame :P

If we do decide to spin a b4, taking the fix for bug 415362 would be good, too.