315759 - Crash [@ libSystem.B.dylib.88.1.2 + 0x3008] accessing Bonjour printer settings

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Samuel Sidler (old account; do not CC)]

Going through the talkback reports, we have a crash when accessing a Bonjour settings page. I don't have a printer so I can't reproduce, but Mike says he has. The following are the current, relevant talkback IDs: TB11579669, TB11588817, and TB11610761. All seem to be using Camino 1.0b1 and all are on Tiger.

Also, this could become a Camino topcrash.

Comment 1

[Mike Pinkerton (not reading bugmail)]

i can repro this 100% on all my machines with my Brother printer. New machines and upgraded machines, so it's nothing to do with the Tiger upgrade process.

Comment 2

[Samuel Sidler (old account; do not CC)]

Nominating as a Camino 1.0 blocker.

Comment 3

[Mark Mentovai]

I don't have zeroconf printers, only CUPS sharing.  The talkback stacks are pretty useless, are the stacks any better with a true debug build?

Comment 4

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

I swear we have an older bug on Bonjour/Rendezvous crashes--I remember Mike cc'ing Stuart on it--but I can't find it for the life of me (it was probably resolved WFM).

Comment 5

[Samuel Sidler (old account; do not CC)]

(In reply to comment #4)
> I swear we have an older bug on Bonjour/Rendezvous crashes--I remember Mike
> cc'ing Stuart on it--but I can't find it for the life of me (it was probably
> resolved WFM).
> 

Mike thought there was one as well, but I can't seem to find it.

Comment 6

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

(In reply to comment #5)
> Mike thought there was one as well, but I can't seem to find it.

Seems he filed it :-)  Bug 293285.  

(Apparently if you leave the --- selected in the Resolution select, it really screws up your searches)

Comment 7

[Mike Pinkerton (not reading bugmail)]

here's the problem. we call 

  NSString* serviceTextRecord = [netService protocolSpecificInformation];

but:

- (NSString *)protocolSpecificInformation

This method has been deprecated. Use TXTRecordData instead.

So we're getting a nil record and don't do null checks on the data so we crash. 

Comment 8

[Mike Pinkerton (not reading bugmail)]

fix coming up.

Comment 9

[Mike Pinkerton (not reading bugmail)]

Attachment: potential patch

this fixes it, but the NSData that we get back is of 0 length (which is all we need to get by the crash). I don't know if the data is of the same format as before (since my case doesn't get any) so i dunno if this is the right patch for real.

Comment 10

[Mark Mentovai]

Comment on attachment 202902 [details] [diff] [review]
potential patch

+#if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_4

You want MAC_OS_X_VERSION_MAX_ALLOWED here.  MAX_ALLOWED is the SDK version, MIN_REQUIRED is the deployment target.  This is such a common mistake, I don't know why they don't just name the macros SDK and DT.

Also, does it make more sense to try TXTRecordData first and fall back to protocolSpecificInformation?

Comment 11

[Simon Fraser [no longer active]]

We should revisit this Rend^H^H^H^H Bonjour code; some of it may have been obsoleted by now-available APIs.

Comment 12

[Simon Fraser [no longer active]]

Comment on attachment 202902 [details] [diff] [review]
potential patch

For tiger, I think we should use [netService TXTRecordData] then [NSNetService dictionaryFromTXTRecordData:] to get the path etc. Otherwise, we fall back on our hand-parsing.

Comment 13

[Samuel Sidler (old account; do not CC)]

Simon said he'd whip up a patch for this. This is blocking beta 2 as of now.

Comment 14

[Simon Fraser [no longer active]]

Attachment: Patch that tries -TXTRecordData first

Comment 15

[Simon Fraser [no longer active]]

Fixed, branch and trunk.

Comment 16

[Mike Pinkerton (not reading bugmail)]

works on my printer yay!