314376 - [10.3] changing trust of certificate [@ libobjc.A.dylib.227.0.0 + 0x1214][@ objc_msgSend + 0x34]

Status: RESOLVED FIXED

(Camino Graveyard :: Security, defect)

Description

[timeless]

FastFind
Talkback Incident ID
	
Talkback Reports
Mozilla Reports Mozilla     Firefox Reports Firefox     Thunderbird Reports Thunderbird     Camino Reports Camino
QuickSearch
Search By: Stack Signature Comments URL
Customize your search:
Vendor: Product: Platform: Build:
Start Date: 				End Date: 		
	(mm/dd/yyyy) 	(hh:mm:ss) 			(mm/dd/yyyy) 	(hh:mm:ss) 	
Sort By: ID Stack Signature Comments URL Build
  
Incident ID: 11236465
Stack Signature	libobjc.A.dylib.227.0.0 + 0x1214 (0x9b7c5214) fe8f357b
Product ID	CaminoTrunk
Build ID	2005102908
Trigger Time	2005-10-29 20:06:57.0
Platform	MacOSX
Operating System	Darwin 7.9.0
Module	libobjc.A.dylib.227.0.0 + (00001214)
URL visited	changing trust of certificate
User Comments	in the certificates dialog i was adding trust for ssl to a certificate
Since Last Crash	2875 sec
Total Uptime	2875 sec
Trigger Reason	SIGSEGV: Segmentation Violation: (signal 11)
Source File, Line No.	N/A
Stack Trace 	
libobjc.A.dylib.227.0.0 + 0x1214 (0x9b7c5214)

Date/Time:      2005-10-29 21:06:50 -0700
OS Version:     10.3.9 (Build 7W98)
Report Version: 2

Command: Camino
Path:    /Applications/Browsers/Camino 11.app/Contents/MacOS/Camino
Version: 1.0+ (1.0+)
PID:     7307
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x5f73796d

Thread 0 Crashed:
0   libobjc.A.dylib                	0x9b7c5214 objc_msgSend + 0x34
1   com.apple.Foundation           	0x9b5b99e4 -[NSArray makeObjectsPerformSelector:withObject:] + 0x108
2   org.mozilla.camino             	0x0008e440 CertificateListData::GetCertificateAt(unsigned int, nsIX509Cert**) + 0x4dd0
3   com.apple.Foundation           	0x9b5b9aec _nsnote_callback + 0xb0
4   com.apple.CoreFoundation       	0x9a25c4a8 __CFXNotificationPost + 0x1b4
5   com.apple.CoreFoundation       	0x9a260eb8 _CFXNotificationPostNotification + 0x340
6   com.apple.Foundation           	0x9b5b7938 -[NSNotificationCenter postNotificationName:object:userInfo:] + 0x74
7   com.apple.Foundation           	0x9b5c3fd4 __NSFireDelayedPerform + 0x104
8   com.apple.CoreFoundation       	0x9a246500 __CFRunLoopDoTimer + 0xf4
9   com.apple.CoreFoundation       	0x9a243860 __CFRunLoopRun + 0x5c8
10  com.apple.CoreFoundation       	0x9a247d74 CFRunLoopRunSpecific + 0x148
11  com.apple.HIToolbox            	0x9b8d6e10 RunCurrentEventLoopInMode + 0xac
12  com.apple.HIToolbox            	0x9b8dd4b4 ReceiveNextEventCommon + 0xf4
13  com.apple.HIToolbox            	0x9b8ff638 BlockUntilNextEventMatchingListInMode + 0x60
14  com.apple.AppKit               	0x992b22ac _DPSNextEvent + 0x180
15  com.apple.AppKit               	0x992c8d2c -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 0x74
16  com.apple.AppKit               	0x992dd0ac -[NSApplication run] + 0x21c
17  com.apple.AppKit               	0x993997bc NSApplicationMain + 0x1d0
18  org.mozilla.camino             	0x0000aa54 start + 0x1b0
19  org.mozilla.camino             	0x0000a8d4 start + 0x30

Comment 1

[timeless]

reproducable: yes

steps:
1. follow the steps in bug 314357 to get a certificate added to your camino (i
can't seem to convince camino to crash, if you do, give that bug a stack trace
instead and then find some other site to get a certificate for this bug ...)
2. cmd-, (or camino>preferences)
3. click the security widget
4. click show certificates
5. click web sites
6. double click the certificate you just added
7. check Identifying web sites (for SSL)
8. click ok

expected results:
no crash

actual results:
crash
certificate will no longer appear in certificates list! - this makes testing this bug a royal pain.

alternate steps:
instead of always accept, you can accept for this session only, which will enable you to reproduce the crash using the same cert once your cert is poisoned...

Comment 2

[Wevah (Nate Weaver)]

The only call to makeElementsPerformSelector: (with or without withObject:) is in NSView+Utils.m line 190:

- (void)removeAllSubviews
{
  // clone the array to avoid issues with the array changing during the enumeration
  NSArray* subviewsArray = [[self subviews] copy];
  [subviewsArray makeObjectsPerformSelector:@selector(removeFromSuperview)];
}

Seems kind of risky to me, even with the array copy.

Comment 3

[Wevah (Nate Weaver)]

(In reply to comment #2)
> The only call to makeElementsPerformSelector: (with or without withObject:) is
> in NSView+Utils.m line 190:

Er, that should be "that's obviously doing object removal of some kind".

Comment 4

[timeless]

minor note about steps, you don't need to actually check ssl, just clicking ok will crash...

Comment 5

[Simon Fraser [no longer active]]

(In reply to comment #1)
> reproducable: yes
> 
> steps:
> 1. follow the steps in bug 314357 to get a certificate added to your camino (i
> can't seem to convince camino to crash, if you do, give that bug a stack trace
> instead and then find some other site to get a certificate for this bug ...)
> 2. cmd-, (or camino>preferences)
> 3. click the security widget
> 4. click show certificates
> 5. click web sites
> 6. double click the certificate you just added
> 7. check Identifying web sites (for SSL)
> 8. click ok
> 
> expected results:
> no crash
> 
> actual results:
> crash

I can't get this to crash.

> certificate will no longer appear in certificates list! - this makes testing
> this bug a royal pain.

This is because NSS now classifies the certificate under "Authorities", because you are using it to sign web sites. This just goes to show how stupid those classifications are.

Comment 6

[Simon Fraser [no longer active]]

(In reply to comment #2)
> Seems kind of risky to me, even with the array copy.

I don't think this is the bug. I think there's a refcounting bug elsewhere.

Comment 7

[Simon Fraser [no longer active]]

I can't reproduce this on 10.4.

Comment 8

[Wevah (Nate Weaver)]

(In reply to comment #6)
> (In reply to comment #
> > Seems kind of risky to me, even with the array copy.
> 
> I don't think this is the bug. I think there's a refcounting bug elsewhere.

You're probably right (especially since the cert stuff doesn't call makeObjectsPerformSelector: at all, that I can see, at least in our code); I just didn't want to keep my wild guesses completely to myself.

Comment 9

[Simon Fraser [no longer active]]

I agree with your analysis that it's the NSView category removeAllSubviews that is the crash location. Maybe that makeElementsPerformSelector: stuff on subviews is risky on 10.3.

Comment 10

[timeless]

happens w/ a clean profile ...

Comment 11

[Wevah (Nate Weaver)]

I can't get this to crash, and I'm on 10.3.9 also.

Comment 12

[Wevah (Nate Weaver)]

FWIW, I can't get the "accept for SSL" checkbox to stick, though.

Comment 13

[Wevah (Nate Weaver)]

Wait; maybe my build isn't new enough. Sorry for the bugspam. :/

Comment 14

[Simon Fraser [no longer active]]

I've managed to crash a couple of times with the steps here, but not every time. There is either a timing factor involved, or some subtlety in the steps that timeless isn't sharing.

Comment 15

[Simon Fraser [no longer active]]

I was able to debug this. What's happening is that an NSView has registered for a notification, which gets fired after that view's window has been dealloc'd, but while the view itself is still pending autorelease.

Comment 16

[Simon Fraser [no longer active]]

Fixed by setting the cert to nil on the certificate view when closing the cert view window.

Comment 17

[Simon Fraser [no longer active]]

I also fixed a couple of bugs relating to the state of the trust checkboxes.