920680 - Opening (malformed?) .eml file hangs TB (Attached GnuPG file has Content-Type:application/octet-stream with file-extensin of .gpg, and GPGServices.service is registered/enabled as .gpg file handler)

Status: RESOLVED WORKSFORME

(MailNews Core :: MIME, defect)

Description

[HJ]

Attachment: Sanitized (no personal info) version of .eml file. The two .gpg attachments are actually plain text (.txt) and can be opened as such.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

I am on Mac OS X 10.6.8, running on a MacBook Pro. I am seeing the following issue on the current stable release [User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8", Application Build ID = "20130801144703"], current beta release [User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0", Application Build ID = "20130910135316"], and the latest Comm-Central "Daily" nightly [User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:27.0) Gecko/20100101 Thunderbird/27.0a1", Application Build ID = "20130924061704"].

Received an email from a friend (who runs Outlook from Office 2010 on 64-bit Win7) with two attachments. Selected the message in the thread pane. TB locked up badly (details below).

Saved the troublesome message as a .eml file to desktop, restarted TB in safe mode with all extensions disabled, tried to open file via "Open Saved Message...". Identical results.

Opened same file in Mac OS X Mail -- file opens without problems, and I am able to extract both attachments as expected.


Actual results:

When trying to open this file (or view it from my Inbox), TB hangs badly: it becomes totally non-responsive, and even after waiting several minutes, Force Quit seems to be the only recourse. Notably, all other running apps become unusably sluggish also when this hang occurs.


Expected results:

Message should be shown in message pane when selecting it in thread pane (when viewing Inbox) or in its own window (when opening .eml file).

At the very worst, if some part of the headers is corrupted or malformed, TB should not hang and lock up the entire system.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Mail structure is pretty simple multipart/mixed mail with simple text/plain part and two attached file parts.
  Content-Type: multipart/mixed
    Content-Type: text/plain
    Content-Type: application/octet-stream; name="　... .gpg"
                  Content-Transfer-Encoding: base64
                  Content-Disposition: attachment; filename="20130919_attachment1.doc.gpg"
    Content-Type: application/octet-stream; name=" ... .gpg"
                  Content-Transfer-Encoding: base64
                  Content-Disposition: attachment; filename="20130919_attachment2.doc.gpg"

Because application/octet-stream, Tb does content sniffing. Data of attaced file is perhaps string data(non-binary, no 0x00 to 0x1F except CR, LF, TAB etc., no 0xFF). If so,  and if View/"Display Attachments Inline" is requested, Tb tries to show it in Inline because it's text data.
Becaue attached file is GnuPG file, data in it is never ordinal text string. It perhaps contains very long string without CR/LF(line break). This may produce severe/critical performance problem in pretty long line/long text data display.

What is your View/"Display Attachments Inline" option choice?
Do you see your problem in Tb with View/"Display Attachments Inline"==Disabled(==Unchcked)?

Comment 2

[WADA:World Anti-bad-Duping Agency]

FYI. 
Bug 736951 is for severe/critical performance problem with XML file of "1.2MB line", when Display Attachments Inline==Enabled(==Checked).

Comment 3

[HJ]

(In reply to WADA from comment #1)

> Becaue attached file is GnuPG file, data in it is never ordinal text string.
> It perhaps contains very long string without CR/LF(line break). This may
> produce severe/critical performance problem in pretty long line/long text
> data display.

The two attachments on the original email that triggered this were indeed GnuPG-encrypted. But as I noted in my comment to the stripped-down .eml I posted to this bug report, TB still locks up even when the email's attachments are plain text. While the attachments posted here still have the ".gpg" suffix in the filename, they are actually one-line plain text files, about 20-30 bytes each. (You can verify this by renaming to ".txt" and opening them in any editor.)

> What is your View/"Display Attachments Inline" option choice?
> Do you see your problem in Tb with View/"Display Attachments
> Inline"==Disabled(==Unchcked)?

I have it disabled, but TB still hangs. (I initially had it enabled, and disabled it following a suggestion by someone on #maildev. It didn't help.)

Also, FWIW, the View/"Message Body As" setting doesn't make any difference here, either. I've tried all four options there (Original HTML, Simple HTML, Plain Text, and All Body Parts) and TB hangs in all cases when trying to deal with this message.

Comment 4

[HJ]

(In reply to WADA from comment #2)
> FYI. 
> Bug 736951 is for severe/critical performance problem with XML file of
> "1.2MB line", when Display Attachments Inline==Enabled(==Checked).

Behavior described in that bug is similar to what I'm seeing, but the root cause is not.

I can't say for sure that TB _never_ recovers from the hang caused by my sample file -- only that it doesn't recover within about 5 minutes (on my MacBook Pro, 2.4GHz Intel Core 2 Duo).

However as you can see from the raw contents of the .eml attachment, the contents are nowhere near 1.2MB long.

Comment 5

[WADA:World Anti-bad-Duping Agency]

> However as you can see from the raw contents of the .eml attachment,
> the contents are nowhere near 1.2MB long.
Sorry, I misunderstood about attached .eml. I thought it's for showing structure only.

I couldn't see any problem in Tb 24.0 with the attached .eml file, even with View/Display Attachments Inline=Enabled(=Checked).
My Tb didn't try to show application/octet-stream & .gpg attachemtnt in Inline, and two attached files are always shown in attachment pane as expected.

Do you have entry related to application/octet-stream or .gpg in Tools/Options/Attachments, Incomming?
Check mimetypes.rdf content in profile directory by Text Editor.

If you can see application/octet-stream or .gpg in mimetypes.rdf, do you see your problem with clean mimetypes.rdf?
(terminate Tb, rename mimetypes.rdf to mimetypes.rdf.Backup, restart Tb)

Do you use PGP relevant add-on such as Enigmail?
Do you see your problem with -safe-mode of Tb?

Comment 6

[HJ]

(In reply to WADA from comment #5)
> Do you have entry related to application/octet-stream or .gpg in
> Tools/Options/Attachments, Incomming?

Nothing for application/octet-stream or .gpg. There is an entry for Document (application/pgp-keys: .asc); Action for this entry is set to "Always Ask".

> Check mimetypes.rdf content in profile directory by Text Editor.
[...]
> If you can see application/octet-stream or .gpg in mimetypes.rdf, do you see
> your problem with clean mimetypes.rdf?

No application/octet-stream or .gpg entries in the mimetypes.rdf in the active TB profile.

> Do you use PGP relevant add-on such as Enigmail?

Yes, I have Enigmail 1.5.2 installed. "Check for Updates" suggests there is no newer version available.

> Do you see your problem with -safe-mode of Tb?

Yes. As I said in my original description above (https://bugzilla.mozilla.org/show_bug.cgi?id=920680#c0), the problem occurrs even after I restart TB in safe mode with all extensions disabled.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Can you check with new profile, with plugin disabled?
1. Start profile manager(thunderbird.bin -p),
   create new profile, start Tb with the profile,
   create Local Folders(cancel account creation, create dummy news account, restart Tb).
   Because new profile, no add-on, mimetypes.rdf is cleared.
2. Create a folder under Local Folders, Drag&Drop .eml file to thread pane of the folder
   (Import of .eml file via Drag&Drop)
3. View the imported mail.
4. Because plugins are obtained by plugin scan, all available plugins is enabled.
   Disable all plugins via Add-on Manager, and view the mail.

If no problem, check with current profile, with -safe-mode, with all plugins disabled, please.

Relation between "data type(text type, type etc.)", mime-type, file extension etc. is registered to system, and in Mac, such data is held in meta file data part too.
(In Win, registered in Windows Registry)
mimetypes.rdf is Tb's local data for such data. If mime-type/file extension is not registered in mimetypes.rdf, data in system is used by Tb.

What is set in OS for application/octet-stream, .gpg?

Comment 8

[HJ]

(In reply to WADA from comment #7)
> Can you check with new profile, with plugin disabled?
> 1. Start profile manager(thunderbird.bin -p),
>    create new profile, start Tb with the profile,
>    create Local Folders(cancel account creation, create dummy news account,
> restart Tb).
>    Because new profile, no add-on, mimetypes.rdf is cleared.
> 2. Create a folder under Local Folders, Drag&Drop .eml file to thread pane
> of the folder
>    (Import of .eml file via Drag&Drop)
> 3. View the imported mail.

Done. Hang still occurs.

> 4. Because plugins are obtained by plugin scan, all available plugins is
> enabled.
>    Disable all plugins via Add-on Manager, and view the mail.

Force-quit TB, restarted, selected new profile from profile manager. Opened
Add-Ons Manager, verified that no add-ons are installed, then went to Plugins
section, disabled (actually set to "Never Activate") all plugins, restarted TB.

Hang still occurs when selecting troublesome message in thread pane.

> Relation between "data type(text type, type etc.)", mime-type, file
> extension etc. is registered to system, and in Mac, such data is held in
> meta file data part too.
> (In Win, registered in Windows Registry)
> mimetypes.rdf is Tb's local data for such data. If mime-type/file extension
> is not registered in mimetypes.rdf, data in system is used by Tb.
> 
> What is set in OS for application/octet-stream, .gpg?

Using RCDefaultApp 2.0.1 in System Preferences:

MIME Types --> application/octet-stream -->
TextEdit (1.6), /Applications/TextEdit.app, UTIs: public.data

Extensions --> gpg --> GPGServices.service(1.9.1)

I now believe this last part is the problem. I discovered and reported
a repeatable crash in the latest stable GPGTools release (2013.08.06),
but the only reply I've received from the developers so far is a note
confirming the crash and saying they were surprised that they'd missed
it in testing.

I just ran the GPGTools uninstaller, verified (via RCDefaultApp) that
the system no longer maps .gpg to GPGServices.service(1.9.1), and found
that the TB lock-up no longer occurs. The puzzling thing is that my
report about GPGServices is a repeatable, nearly instantaneous _crash_,
whereas TB seems to _hang_.

I added a comment to my original bug report over on GPGTools, saying
that this issue affects more than just the tools suite itself, due to
the system-wide effect you've kindly explained above. So for now I'll
conclude that the problem is most likely _not_ with TB, but I will
confirm once I've had a chance to install a newer version of GPGTools
where this bug is fixed.

Comment 9

[HJ]

I just got a debug build of GPGServices from the GPGTools team. Installed it and the crash I reported to them is fixed in this build. However, the hang in TB still occurs. The steps I took to test this:

1) Ran the GPGTools uninstaller. Verified (via "which gpg" and "which gpg2" from Terminal) that the uninstaller really did what it was supposed to do. Also verified that /Library/Services/GPGServices.service was similarly uninstalled.

2) Opened System Preferences > RCDefaultApp > Extensions and made sure that the default application for .gpg, .pgp, .asc, and .sig was set to "<disable>".

3) Created clean TB "test" profile, and added "test folder" under Local Folders, as per your instructions. Manually disabled all plugins, restarted TB. Dragged problematic .eml file into thread pane of test folder. Was able to view message with no problems.

4) Using the current stable release of GPGTools (2013.08.06), installed everything _except_ GPGServices -- that is, GPGMail, GPGKeychainAccess, GPGPreferences, and MacGPG2. Then installed the debug-enabled nightly build of GPGServices I received from the GPGTools team. Then Opened System Preferences > RCDefaultApp > Extensions again and observed that the default application for .gpg, .pgp, .asc, and .sig is still set to "<disable>". In other words, the GPGServices installer does not mess with default app settings. Found a known-good file/signature pair (file.txt, file.txt.asc) in Finder, and ran "OpenPGP: Verify" from the context menu. Signature verifies without any problems, so the original crash I'd reported is indeed fixed in this nightly build. 

5) Re-launched TB with the test profile, and verified that I was still able to view the message. In other words, the mere _presence_ of GPGServices doesn't cause any problems.

6) Opened System Preferences > RCDefaultApp > Extensions again and set the default application for .pgp, .asc, and .sig to /Library/Services/GPGServices.service, but made sure that the default for .gpg is still "<disable>". Re-launched TB with the test profile, and verified that, unsurprisingly, I was still able to view the message. 

7) Opened System Preferences>RCDefaultApp>Extensions again and set the default application for .gpg to /Library/Services/GPGServices.service. Re-launched TB with the test profile. Now, attempting to view the message causes the hang.

Honestly, at this point I can't tell if the problem is with TB or GPGServices. What I am sure about is:

a) Enigmail isn't the culprit (since the clean TB profile has no add-ons enabled);
b) The crash I reported earlier against GPGServices is fixed; and
c) Associating the non-crashing GPGServices with .gpg _still_ causes TB to hang on my machine.

For what it's worth, top shows that TB uses almost no CPU when it sits idle (0.0%-0.1%). But as soon as I click on the troublesome message in the thread pane, TB shoots up to about 80% CPU and stays there until I force quit. In case it would help, I am attaching the stack trace that appears when I force-quit TB. I will also send this to the GPGTools guys to see if they can figure out what's causing the hang.

Please let me know if there's any other debug testing I can do.

Comment 10

[HJ]

Attachment: Stack trace from TB hang

Comment 11

[WADA:World Anti-bad-Duping Agency]

Associated mime-type to .gpg is application/gpg-keys
> http://www.filesuffix.com/en/extension/gpg
Check Tb's behavior when following header, please.
> Content-Type: application/gpg-keys; name="　... .gpg"
>               Content-Transfer-Encoding: base64
>               Content-Disposition: attachment; filename="... .gpg"
If it's shown as attachment in attachment pane, try "Open by application", please.

In Win, relation between file-extension and application is registered to Windows Registry entry like following.
  file extension of ??? => Command line to invoke application.
     "C:\Program Files\ ... \modulename.exe" "&1" "&2" ...
IIRC, Adobe Reader on Linux had problem with "space in passed file name".
  Adobe Reader resgitered "\Library\modulename &1 ..." (&1 without quot).
  So, if file name contains space, file name is cut at space.
This kind of problem may produce "error, wait etc. in application" and "Tb's loop like action while waiting for return from application".
Please rule out such problem.

Comment 12

[WADA:World Anti-bad-Duping Agency]

Confirming per detailed test result in comment #9.

Comment 13

[WADA:World Anti-bad-Duping Agency]

Following is GnuPG issues found by Google search for "file extension .gpg mime".
 https://dev.guardianproject.info/issues/1455
 https://dev.guardianproject.info/issues/1456
".gpg file attachment support" is still in progress?

Comment 14

[HJ]

(In reply to WADA from comment #11)
> Associated mime-type to .gpg is application/gpg-keys
> > http://www.filesuffix.com/en/extension/gpg

By default, this entry is not defined in the list of MIME types on my system (System Preferences > Default Apps > MIME Types). If I try to add it, I can navigate to the path where my gpg executable is, but I am not able to add it as the default application for this type (it remains greyed out).

What I am able to do is associate it with /Library/Services/GPGServices.service, as mentioned earlier. But that does not seem to change anything: if the default application associated with the extension ".gpg" is set to "<disable>", I can view the .eml with no problems. If I set it to /Library/Services/GPGServices.service, TB hangs when I view the message.

By the way, I am seeing all of the above on TB 24.0.1 final (release) -- before, I was testing with the beta.

> Check Tb's behavior when following header, please.
> > Content-Type: application/gpg-keys; name="　... .gpg"
> >               Content-Transfer-Encoding: base64
> >               Content-Disposition: attachment; filename="... .gpg"

I manually edited the .eml to have the above headers instead of what was there originally (which was "Content-Type: application/octet-stream;", with everything else the same). Didn't help.

> If it's shown as attachment in attachment pane, try "Open by application",
> please.

Opening the attachment has never been the issue. The problem is simply that if I have the .gpg extension mapped to GPGServices.service, TB immediately hangs when I select the message in the message list. Tweaking the MIME types doesn't seem to do anything at all.


> In Win, relation between file-extension and application is registered to
> Windows Registry entry like following.
>   file extension of ??? => Command line to invoke application.
>      "C:\Program Files\ ... \modulename.exe" "&1" "&2" ...
> IIRC, Adobe Reader on Linux had problem with "space in passed file name".
>   Adobe Reader resgitered "\Library\modulename &1 ..." (&1 without quot).
>   So, if file name contains space, file name is cut at space.
> This kind of problem may produce "error, wait etc. in application" and "Tb's
> loop like action while waiting for return from application".
> Please rule out such problem.

The two filenames have no spaces in them, so I can rule out this issue.

Please let me know if there's anything else I can try. For now, all I can see is that associating .gpg with GPGService causes TB to hang on this message, no matter what else I do. And I know that the Service itself is working, because I can do the usual encrypt/decrypt/verify from the Services context menu in Finder.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to HJ from comment #14)
> Opening the attachment has never been the issue.
> The problem is simply that if I have the .gpg extension mapped to GPGServices.service,
> TB immediately hangs when I select the message in the message list.
> Tweaking the MIME types doesn't seem to do anything at all.

When application/gpg-keys or application/octet-stream&file-extension=gpg, your Tb looks to call associated program always.
application/octet-stream case may be;
  Tb tries to do content sniffing for inline display of application/octet-stream.
  Because associated program=GPGServices exists, Tb calls GPGServices in order to
  obtain decyphered data.
  This is perhaps done before check of "Display Attachments Inline"==Disabled.
application/gpg-keys case may be produced by Enigmail, and application/gpg-keys may be "inline displayable attachment" for Enigmail if associated program exists.

Do you see your problem with Enigmail disabled, with Content-Type:application/gpg-keys?
Because plugin may be relevant to problem too, disable all plugins via Addon Manager.

> The two filenames have no spaces in them, so I can rule out this issue.
"filename" in this context is "full path of temporary file, to where Tb saved attached file after base64 decoding". 
This "full path of temporary file" may be different when temporary file is passed from Tb to other than external application program, such as add-on, protocol handler etc.
If Disk Cache file is used to pass data to other program, file extension is not added, and programs who rely on file extension produces problem.

To surely rule out file path related issues, and to see what happens while Tb is freezing, please check file access by Tb and GPGService using opensnoop, FileMonitor, FileMon etc. 
> http://osxdaily.com/2011/04/22/monitor-mac-os-x-filesystem-usage-access-with-opensnoop/
> http://mac.majorgeeks.com/mg/sortname/monitoring.html

Comment 16

[WADA:World Anti-bad-Duping Agency]

NSPR log with all:5 may be helpful.
(1) Create new profile, create dummy news acount to create "Local Folders" account.
    Create Inbox, FolderX under Local Folders.
    Copy mail-1(application/gpg-keys) and mail-2(application/octet-stream) to Inbox.
    (or Drag&Drop .eml file to thread pane of Inbox == Import of .eml by Drag&Drop)
    Select Inbox at folder pane(FolderX is not opened when Tb is restarted)
(2) Restart Tb with NSPR logging enabled.
    See bug 402793 comment #28. Use NSPR_LOG_MODULES = timestamp,all:5
(3) Click FolderX just before test.
    => nsMsgDatabase::Open( .../Mail/Local Folders/FolderX.msf, FALSE, xxxxxxxx, TRUE)
       is logged(because MSDB:5 is enabled by all:5)
    This log can be used as "eye catcher"
(4) View mail in Inbox.
(5) After a while, terminate Tb, keep backup of log file,
    check log file content by Text Editor.

Comment 17

[HJ]

(In reply to WADA from comment #16)
> NSPR log with all:5 may be helpful. [...]

Hi WADA,

Thanks for the detailed instructions. I did the NSPR logging stuff first, using the steps above. Attached are two logfiles: one with the application/gpg-keys version of my .eml, the other with the application/octet-stream.

The hang occurs in both cases, as before. I wasn't sure if anything prior to the log line "nsMsgDatabase::Open( .../Mail/Local Folders/FolderX.msf" in each logfile might be useful, so I did not trim the files at all -- only scrubbed the personal details and gzipped.

For reference, the following is the approximate timing for each test from my system clock (+/- 2 sec), all in UTC:

22:08:00 launched TB
22:08:30 clicked on FolderX
22:09:00 clicked on Inbox, then selected the gpg-keys version of the .eml
22:09:30 force-quit TB

22:13:00 launched TB
22:13:30 clicked on FolderX
22:14:00 clicked on Inbox, then selected the octet-stream version of the .eml
22:14:30 force-quit TB

I don't quite know what to look for in these logfiles, however they both seem to simply end right around the timestamp when the hang occurs... so perhaps there is nothing useful here. I will investigate your suggestion in Comment 15 about full paths nexxt.

Comment 18

[HJ]

Attachment: tb_debug_application-gpg-keys.log.gz

TB debug log from trying to view .eml file whose attachment headers were manually edited to be "application/gpg-keys".

Comment 19

[HJ]

Attachment: tb_debug_application-octet-stream.log.gz

TB debug log from trying to view .eml file whose attachment headers were manually edited to be "application/octet-stream".

Comment 20

[WADA:World Anti-bad-Duping Agency]

(In reply to HJ from comment #17)
> however they both seem to simply end right around the timestamp when the hang occurs...
> so perhaps there is nothing useful here.
It's an importance evidence of "Tb does't do any jobs which produces NSPR log by all:5 after mail view is requested".

"Freeze of Tb" is loop type?(CPU 100%) Or wait type?(CPU 0%)
How about Virtual Memory size increase while freezing?
What kind of logs are seen after "eye catcher" before "start of freezing"?
Is there any interesting difference between log with "application/gpg-keys" and log with "application/octet-stream"?

Comment 21

[HJ]

(In reply to WADA from comment #20)

> "Freeze of Tb" is loop type?(CPU 100%) Or wait type?(CPU 0%)

Loop type, definitely. Though as I wrote earlier (see Comment 9), top (as well as Activity Monitor.app) shows the CPU pegging at 80%, not 100%.

> How about Virtual Memory size increase while freezing?

Nothing significant. 113-114 MB when idle right after launch, 120-121 MB when hanging with the CPU at 80%.

> What kind of logs are seen after "eye catcher" before "start of freezing"?
> Is there any interesting difference between log with "application/gpg-keys"
> and log with "application/octet-stream"?

As I mentioned, I unfortunately don't know enough to make any definite conclusions about whether or not there's anything interesting in the attached logfiles between the "nsMsgDatabase::Open(" line and the end of the logfile (which corresponds to the start of freezing). I'll have to defer to someone who understands the contents much better than I can.

From a quick glance, the two logs look pretty similar to me (apart from the timestamps, of course)... but again, I'm unfortunately no expert at this.

I'll report back as soon as I've had time to investigate your suggestions in Comment 15.

Comment 22

[HJ]

Attachment: opensnoop output for "thunderbird"

Comment 23

[HJ]

Attachment: FileMon output, filtered by "thunderbird"

Comment 24

[HJ]

(In reply to WADA from comment #15)

> Do you see your problem with Enigmail disabled, with
> Content-Type:application/gpg-keys?
> Because plugin may be relevant to problem too, disable all plugins via Addon
> Manager.

(Hi WADA, sorry for the long delay -- just getting back to this now.)

Yes, the problem still occurs with all plugins _and_ add-ons disabled (including Enigmail). Note: in the time since I originally filed this report, TB stable has gone from 17.0 to 24.2.0, which is what I'm running now. The hang still occurs with this latest version.

> To surely rule out file path related issues, and to see what happens while
> Tb is freezing, please check file access by Tb and GPGService using
> opensnoop, FileMonitor, FileMon etc. 
> > http://osxdaily.com/2011/04/22/monitor-mac-os-x-filesystem-usage-access-with-opensnoop/
> > http://mac.majorgeeks.com/mg/sortname/monitoring.html

Plain-text output of "sudo opensnoop | grep -i thunderbird" is attached. As for GPGServices, the only output from opensnoop is a series of the same "dtrace: error on enabled probe ID 4" lines as in the TB log -- there is no specific mention of GPGServices (nor TB, for that matter) at all.

Plain-text output of FileMon, filtering on "thunderbird", is also attached. I don't know enough about what to look for to see if it contains any obviously interesting lines.

Please let me know what I can do to assist in debugging this further. Thanks!

Comment 25

[HJ]

Just went back and checked my test .eml file against TB 52.0b3 on Mac OS X El Capitan (10.11.6). File opens flawlessly and attachments are decoded without incident, so it seems the underlying bug has been fixed since the original bug report.

Suggest closing this bug as resolved. Recent versions of TB no longer work on the version of OSX against which I filed this originally, so I can't say for sure that the bug is no longer valid as reported -- only that it doesn't affect the current version of TB.

I assume the most appropriate status should be RESOLVED - WORKSFORME.