273560 - Crash when selecting inbox after selecting saved search folder before search complete [@ 0x00000000 - nsMsgSearchSession::NotifyListenersDone]

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[Paul Minear]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Created a saved search folder searching for a text string in message body. 
After saving folder, clicked on saved search folder to start search.  While
search still in progress, clicked another folder in same account, and
Thunderbird crashed.  Problem seen since introduction of saved search folders

Reproducible: Always
Steps to Reproduce:
1. Create a saved search folder with a time-consuming search, ie. search message
body
2. Click on the saved folder to start the search
3. Before the saved search is complete, click on another folder
4. Thunderbird crashes
Actual Results:  
Thunderbird crashed

Expected Results:  
saved search to be canceled and selected folder contents displayed

Comment 1

[Dan G. Lunde]

I can confirm this behaviour in Thunderbird version 0.9 (20041103).

However, it seems to only happen the first time you create a saved search. After
letting the first search complete, I could create new complex search-folders and
change to other folders before the search-folder operation had completed. Can
you confirm this, Paul?

Comment 2

[Paul Minear]

Yes, following the procedure listed below does *NOT* cause a crash:

1. Run a time-intensive saved-search folder to completion.
2. Click on another time-intensive saved search folder
3. Before 2nd search is done, click on any other folder or saved-search folder
4. Thunderbird does not crash

This behavior validated on Thunderbird 1.0 (20041206)

Comment 3

[Dan G. Lunde]

I continued with Thunderbird version 1.0 (20041206), and the crash can still be
reproduced. This time I used a slightly different approach than the test I did
with 0.9:

1. Select a mail folder with ~3000 messages in
2. ctrl-shift-f, search for messages where body contains -- 
3. Start search
4. Quickly press 'Save as Search folder', name search 'aa'
5. Exit 'Search Messages' dialog
6. Press the newly created "aa" search folder
7. Continue selecting other mail folders, including the "aa" search folder.
8. Thunderbird will crash after a few clicks.

Comment 4

[Hermann Josef Hill]

The bug definitely exists in Thunderbird Version 1.0 (20041206).

I use a saved search folder for "is Junk" on my inbox (~300 mails) and when I
change quickly back and forth between the inbox and the saved search folder it
crashes after some (from 5 to 25) clicks. When I use more than one saved search
folder, the problem seems to happen more often.

Comment 5

[Hermann Josef Hill]

The bug definitely exists in Thunderbird Version 1.0 (20041206).

I use a saved search folder for "is Junk" on my inbox (~300 mails) and when I
change quickly back and forth between the inbox and the saved search folder it
crashes after some (from 5 to 25) clicks. When I use more than one saved search
folder, the problem seems to happen more often.

Comment 6

[Tal Cohen]

I also repeatedly encounter this bug -- not just when selecting the Inbox, but 
when selecting any other folder.

In particular, sometimes a new mail message seems to appear in the saved search 
folder after mail download. In which case, the following leads to a crash, 
always:

1. Read new mail in Inbox, press Space;
2. When asked "Advance to next unread message in [Saved Search Folder]", click 
Yes (specifically, by hitting the spacebar).
3. The search begins; before it ends, press space;
4. When asked "Advance to next unread message in [other folder]", click Yes 
(space).
5. Thunderbird crasehs.

Comment 7

[John Navas]

Particularly since Thunderbird lacks auto-save of Compose-in-progress, I think
this bug should be elevated to Blocking -- it's caused me to lose so much work
(Compose-in-progress) that I'm giving up on Saved Searches (aka Virtual Folders)
until it gets fixed.

Comment 8

[David :Bienvenu]

trunk builds have auto save of composed messages. In any case, you're not
allowed to set the blocking + flag unless you are a driver...

I have not been able to reproduce this crash, but I'll try some more.

Comment 9

[John Navas]

Reproduced again in Thunderbird version 1.0.2 (20050317) on Windows XP SP2
running on a 2 GHz Mobile Pentium 4 notebook (IBM ThinkPad T30).

What I've got is quite a few different Saved Searches (aka Virtual Folders), all
of which search multiple real folders, including a (real) folder with over 1300
messages, so each Saved Search takes several seconds to complete.

I normally have 10 Extensions installed, and with all of them enabled I'll get a
crash every time when clicking on a new folder (real or virtual) before a Saved
Search has completed.  When I disable all 10 Extentions, the frequency of crash
goes way down, but I can still get a crash when quickly clicking on several
Saved Searches in sequence (Incident ID TB5176714K) or when quickly clicking
back and forth between Saved Searches and real folders (Incident ID TB5177201E).

I've checked to see if any particular Extension has any bearing, but it seems
just a matter of frequency of crashing going up as more Extensions are enabled.

I speculate that this may be related to the new bug 290851 I just entered, since
both are crashes that seem to be caused by Saved Search not being allowed to
complete.

Thanks for the explanation on the Blocking flag -- I'm new to this, and the
on-line help wasn't terribly helpful.  ;)

I'm reluctant to use a Trunk Build just to get Compose Auto-Save -- I think that
might be jumping from the frying pan into the fire.  :)

Comment 10

[David :Bienvenu]

OK, I've reproduced this, and I believe I have a fix.

Comment 11

[John Navas]

Great!  Terrific!  Thank you!

Comment 12

[David :Bienvenu]

Attachment: proposed fix

Comment 13

[David :Bienvenu]

Comment on attachment 181299 [details] [diff] [review]
proposed fix

simple null check to prevent frequent crasher.

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 181299 [details] [diff] [review]
proposed fix

a=asa

Comment 15

[David :Bienvenu]

fixed on trunk.

Comment 16

[John Navas]

If the fix made it into the Thunderbird Trunk Build 20-Apr-2005, then the
problem seems better, but not completely fixed -- see Incident ID TB5241578K.

Comment 17

[John Navas]

To amplify my prior post, I ran another test, clicking back and forth between
long and complex Saved Searches (of multiple real folders, including a real
folder with over 1300 messages) and real folders.  10 extensions are installed,
of which 8 are enabled (2 not playing nice with this build).  After about a half
dozen such clicks, I got another crash -- see Incident ID TB5249131K.

Comment 18

[timeless]

Incident ID: 5176714
Stack Signature	0x00000000 60c6166f
Product ID	Thunderbird10
Build ID	2005031711
Trigger Time	2005-04-18 11:31:10.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	
User Comments	Clicked on several different long Saved Searches without waiting
for each one to finish, with a crash on about the 8th click.
Since Last Crash	11 sec
Total Uptime	1324993 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x00000000
nsMsgSearchSession::NotifyListenersDone 
[e:/builds/tinderbox/Tb-Aviary1.0.1/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp,
line 586]
nsMsgSearchSession::TimerCallback 
[e:/builds/tinderbox/Tb-Aviary1.0.1/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp,
line 525]
nsTimerImpl::Fire 
[e:/builds/tinderbox/Tb-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 382]
nsAppShellService::Run 
[e:/builds/tinderbox/Tb-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[e:/builds/tinderbox/Tb-Aviary1.0.1/WINNT_5.0_Depend/mozilla/mail/app/nsMailApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)

5177201 was the same as 5176714

Incident ID: 5241578
Stack Signature	nsMsgSearchSession::GetRunningScope 12dab36d
Product ID	ThunderbirdTrunk
Build ID	2005042006
Trigger Time	2005-04-20 23:05:31.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	thunderbird.exe + (0042abbd)
URL visited	
User Comments	Testing fix to Bug 273560
Since Last Crash	894 sec
Total Uptime	1021 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp,
line 645
Stack Trace 	
nsMsgSearchSession::GetRunningScope 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp,
line 645]
nsTimerImpl::Fire 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 383]
nsAppStartup::Run 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 145]
main 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mail/app/nsMailApp.cpp,
line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)

Incident ID: 5249131
Stack Signature	nsMsgSearchScopeTerm::TimeSlice e1f2e065
Product ID	ThunderbirdTrunk
Build ID	2005042006
Trigger Time	2005-04-21 08:47:02.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	thunderbird.exe + (0042cb2c)
URL visited	
User Comments	Testing fix for Bug 273560 in Thunderbird Trunk Build 20-Apr-2005.
Since Last Crash	33526 sec
Total Uptime	34547 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchTerm.cpp,
line 1494
Stack Trace 	
nsMsgSearchScopeTerm::TimeSlice 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchTerm.cpp,
line 1494]
nsTimerImpl::Fire 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 383]
nsAppStartup::Run 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 145]
main 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mail/app/nsMailApp.cpp,
line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)

Comment 19

[John Navas]

Is this fix in Mozilla Thunderbird trunk build 28-Apr-2005 1014?  If so, then
the problem is *not* completely fixed, because it easily crashed in my tests of
clicking on Inbox before a long complex Saved Search had completed -- see
Incidents TB5451173Y, TB5451511Z, and TB5451569X.

Comment 20

[David :Bienvenu]

those talkback id's all show a seemingly un-related stack trace:

0x0267cb7e
nsMessengerMigrator::SetMailCopiesAndFolders 
[e:/builds/tinderbox/Tb-Aviary1.0.1/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMessengerMigrator.cpp,
line 919]
xpcom_core.dll + 0x2b44b (0x6035b44b)
nsNSSComponent::StopCRLUpdateTimer 
[e:/builds/tinderbox/Tb-Aviary1.0.1/WINNT_5.0_Depend/mozilla/security/manager/ssl/src/nsNSSComponent.cpp,
line 882]


and the build id is 2005031711, which is from before the fix was checked in, if
that build id is being correctly reported by talkback.

Comment 21

[John Navas]

On the issue of the Build ID in my last series of Incidents, that may be because
I installed "version 1.0+ (20050428)" over the top of the 1.0.2 Release.

To check, I uninstalled all Extensions and Thunderbird, deleted the Program
Files directory, and then did a fresh install of "version 1.0+ (20050428)". 
When I triggered the crash, Talkback did *not* come up.  Even when I tried to
launch Talkback.exe directly, it would *not* start up.  Reinstalling Thunderbird
did *not* help.  Something is wrong with Talkback in that build.

So I uninstalled Thunderbird again, and this time did a fresh install of
2005-04-27-05-trunk (the prior nightly trunk build), verified after install as
"version 1.0+ (20050427)".  I easily forced the crash again and sent it in as
Incident TB5457628Q, which correctly reports:

 Build Identifier
   2005042704

 Deployment Identifier
   MozillaOrgThunderbirdTrunkWin322005042704

Please check this incident.  Thank you.

Comment 22

[David :Bienvenu]

ah, much better:

0x00000000
nsMsgSearchSession::NotifyListenersDone 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp,
line 586]
nsMsgSearchSession::TimerCallback 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp,
line 525]
nsTimerImpl::Fire 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 383]

Comment 23

[David :Bienvenu]

Attachment: an other fix...

we should be interrupting the search before deleting the search session...I've
had this patch in my tree for a while - it might be why I haven't been able to
reproduce this crash.

Comment 24

[chris hofmann]

Comment on attachment 182201 [details] [diff] [review]
an other fix...

a=chofmann

Comment 25

[David :Bienvenu]

please try tomorrow's trunk build - I don't know for sure if this will fix it or
not...

Comment 26

[John Navas]

I confirm this problem as RESOLVED-FIXED in Thunderbird nightly trunk
03-May-2005 0850.  Thank you!

Comment 27

[David :Bienvenu]

great, thx, marking verified.

Comment 28

[John Navas]

CAVEAT: While the crash has been fixed, there remains a behavior problem. If a
long and complex Saved Search is selected, a regular folder is then selected,
and a long and complex Saved Search is then immediately selected (without any
delay in the regular folder), that Saved Search will not be performed, staying
with an empty result set forever. Work-around: When selecting a regular folder
after having selected a Saved Search, wait a few seconds in the regular folder
before selecting a Saved Search.

Comment 29

[John Navas]

*** Bug 290851 has been marked as a duplicate of this bug. ***

Comment 30

[delcour]

Hello! I just installed this build:

version 1.0+ (20050504)

... because I wanted to verify wether the bug still exists or not. At first view
it seemed to be fixed. I moved quick between the saved search folders (partyally
verly large) and some previewd mails. No crash anymore ...

... until I closed thunderbird afterwards. Then the talkback agent cames up.

I startet Thunderbird again and used it without saved search. No crash. Closed
Thunderbird. No crash.

Then I started Thunderbird again. Moved quick between saved search folders.
Closed Thunderbird and the Talkback agent came up.

I do not know whether it is the same bug-reason or it is a new bug.

Comment 31

[delcour]

Yesterday I could easyly reproduce the incedent. Today not.

Here are the incedent numbers:

TB5615081W, TB5594351Y, TB5594323X

Comment 32

[John Navas]

With Thunderbird nightly trunk 06-May-2005 0755, I cannot produce the problem
described in Additional Comment #30 From [e-mail]  2005-05-05 05:04 PDT

Comment 33

[Tal Cohen]

Seems like the bug is still there... (TB 1.0.6, installed over 1.0.2). I have 
just sent Talkback details (including this bug number).

Brief description of incident: I pressed Space (for "Next unread"); a dialog 
popped up, "Advance to next unread message in [search folder]?"; I hit Space 
for "Yes" (the default). TB moved to the search folder; I *very quickly* 
pressed Space again (to move to the next folder) and Space (for "Yes"), and... 
boom.

Comment 34

[Jaime Mitchell (use [e-mail] for email)]

(In reply to comment #33)
> Seems like the bug is still there... (TB 1.0.6, installed over 1.0.2). I have 
> just sent Talkback details (including this bug number).

That is because it is fixed in the trunk and not the branch. The fix will be
included in Thunderbrid 1.5 when it is released.

Comment 35

[OstGote!]

*** Bug 277418 has been marked as a duplicate of this bug. ***

Comment 36

[Tal Cohen]

Seems to be happening again (TB1.5). I've sent several reports via Talkback; any need to upload a Talkback dump as an attachment here?

Comment 37

[John Navas]

(In reply to comment #36)
> Seems to be happening again (TB1.5). I've sent several reports via Talkback;
> any need to upload a Talkback dump as an attachment here?

Confirmed. See Incident ID TB14614299X. It can be hard to reproduce -- only happens some of the time -- but there's definitely still a bug -- it needs to be reopened!

Comment 38

[David :Bienvenu]

Tal, yes, incident id's would be helpful. John, that looks like a completely different stack trace, so I suspect that's a different bug, probably with similar steps to reproduce. It would be useful to know if Tal's stack trace is the same as yours.

Comment 39

[timeless]

so, my quick read of branches doesn't show this patch made the 18 branch or the tb 15 release which means I wouldn't expect the crashes not to happen there.

jaime was slightly misinformed. currently it looks like TB2 would be the first release unless this makes a tb1.5.x.y release.

Comment 40

[timeless]

All of tal's crashes look like this one by (john)
Incident ID: 14614299
Stack Signature	0x0331ff51 3088fab0
Product ID	Thunderbird15
Build ID	2005120115
Trigger Time	2006-02-01 00:58:13.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	
User Comments	Reproduced Bugzilla Bug 273560
Since Last Crash	1022090 sec
Total Uptime	1716145 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x0331ff51
nsMsgLocalMailFolder::OnStopRunningUrl  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 3340]
nsUrlListenerManager::BroadcastChange  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsUrlListenerManager.cpp, line 97]
nsUrlListenerManager::OnStopRunningUrl  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsUrlListenerManager.cpp, line 123]
nsMsgProtocol::OnStopRequest  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 397]
nsMailboxProtocol::OnStopRequest  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/local/src/nsMailboxProtocol.cpp, line 395]
nsInputStreamPump::OnStateStop  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 507]
0x0350a230
nsMailboxProtocol::`vftable'
nsGopherChannel::AddRef  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/netwerk/protocol/gopher/src/nsGopherChannel.cpp, line 98]
0x8b560c45

They are:
Incident ID: 14597311
Incident ID: 14583543
Incident ID: 14441697
Incident ID: 14436762

Except for tal's last one, which is:
Incident ID: 14346249
Stack Signature	0x00000000 b11039ed
Product ID	Thunderbird15
Build ID	2005120115
Trigger Time	2006-01-24 00:23:01.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	
User Comments	Undo-delete did not work; I opened the Trash folder, and.... crash.
Since Last Crash	148235 sec
Total Uptime	148235 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x00000000
nsMsgMailSession::OnItemEvent  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMsgMailSession.cpp, line 262]
nsMsgDBFolder::NotifyFolderEvent  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/util/nsMsgDBFolder.cpp, line 4644]
nsMsgDBFolder::OnStopRunningUrl  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/util/nsMsgDBFolder.cpp, line 1306]
nsMsgLocalMailFolder::OnStopRunningUrl  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/local/src/nsLocalMailFolder.cpp, line 3355]
nsUrlListenerManager::BroadcastChange  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsUrlListenerManager.cpp, line 97]
nsUrlListenerManager::OnStopRunningUrl  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsUrlListenerManager.cpp, line 123]
nsMsgProtocol::OnStopRequest  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 397]
nsMailboxProtocol::OnStopRequest  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/local/src/nsMailboxProtocol.cpp, line 395]
nsInputStreamPump::OnStateStop  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 507]
0x0356b460
nsMailboxProtocol::`vftable'
nsGopherChannel::AddRef  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/netwerk/protocol/gopher/src/nsGopherChannel.cpp, line 98]
0x8b560c45

Comment 41

[Tal Cohen]

timeless, thanks for digging out my incidents.

Incident 14346249 seems related to a different bug; I was not dealing with a search folder when it happened.

Comment 42

[John Navas]

(In reply to comment #38)
> ... John, that looks like a completely
> different stack trace, so I suspect that's a different bug, probably with
> similar steps to reproduce. ...

I think it probably is a different bug because I haven't been able to reproduce it in many tries. When that one crash occurred, TB had been running for quite some time. I clicked a complex saved search, then Local Folders (by accident), then Inbox, whereupon it crashed. Since then I haven't been able to make it crash.

Comment 43

[John Navas]

(In reply to comment #38)
> ... John, that looks like a completely
> different stack trace, so I suspect that's a different bug, probably with
> similar steps to reproduce. ...

Happened again: TB14660524G

Comment 44

[Tal Cohen]

I suspect (no confirmation yet) that this happens if TB is building the summary file for some folder or another in the background (perhaps the folder we left before entering the search, or we select after leaving the search -- no idea). Can this be checked from the incident data?

Comment 45

[John Navas]

(In reply to comment #44)
> I suspect (no confirmation yet) that this happens if TB is building the summary
> file for some folder or another in the background (perhaps the folder we left
> before entering the search, or we select after leaving the search -- no idea).
> Can this be checked from the incident data?

I seem to remember that TB was building a summary file for the Trash folder when TB14614299X happened. However, I'm unable to reproduce the problem by forcing a summary file rebuild before clicking on the saved search and then inbox.

Comment 46

[timeless]

john: you need a newer build, try trunk in a few weeks (currently it's very unstable, so now isn't quite the time...)

i'm not sure when / if bienvenu plans to commit this to some branch you could use.

Comment 47

[John Navas]

(In reply to comment #46)
> john: you need a newer build, try trunk in a few weeks (currently it's very
> unstable, so now isn't quite the time...)
> 
> i'm not sure when / if bienvenu plans to commit this to some branch you could
> use.

Thanks for the suggestion, but the problem is rare enough that I'm not interested in running non-production code.

Comment 48

[David :Bienvenu]

both these fixes are in 1.5 - timeless must have misread the branches. The crash reported in 1.5 has a different stack trace and I don't know that there's a fix on the trunk for that or not (but I suspect not).

Comment 49

[John Navas]

(In reply to comment #48)
> both these fixes are in 1.5 - timeless must have misread the branches. The
> crash reported in 1.5 has a different stack trace and I don't know that there's
> a fix on the trunk for that or not (but I suspect not).

Then we need to either get this bug reopened or a new bug entered!

Comment 50

[David :Bienvenu]

yes, a new bug would be appropriate.

Comment 51

[John Navas]

(In reply to comment #50)
> yes, a new bug would be appropriate.

Done.  Bug 325768.