Zip of test files is in the URL, not as an attachment, as it's 80 MB. However it may be difficult to reproduce anything with those files. Mostly, they import OK for me on Win XP. Six cases reported to me of intermittent freezing and crashing of the same WAV/AIFF files on Mac and Windows during February 2010, similar number of different people the month before.

Koz had a problem testing 1.3.12 rc1 on OS X 10.6.2 where File > Open then open WAV and AIFF files caused a repeatable crash:
http://forum.audacityteam.org/viewtopic.php?f=17&t=26840&p=76065#p76049
 
Right-click > Open with imported the files OK. MC says the crash report isn't a lot of help as there's not much information about the thread that crashed except that it's somewhere in quartz. He noted there were far more threads running than we would have expected, and he's going to memory test a debug build later on.

It's a fairly consistent theme with the history of this flaky PCM import problem that right-click > Open with (or drag) is more likely to succeed. On XP, when I couldn't always reproduce the original problem where 16-bit WAV/AIFF imported as noise into 24-bit projects set to "copy in", it was often right-click or drag that made the import work. File > Open or File > Import usually failed. Also, files that were made by a CD ripper were more likely to import (with any import method) than those created by Audacity.

Any updates on this?  What is the average ratio of failure for these files?  I tried opening each of the 5 files 10 times with no issues on intel mac 10.5.8.
Also the link to the forum appears to be dead, and I can't retrieve it by searching in the forum.  If some people can reproduce it more crash reports would be helpful - also to know if the crash happens before or after the progress bar starts and finishes, since the one crash log appears to be a GUI related crash.

(In reply to comment #3)

Ditto Michael's comment per my testing on Win XP. Tried File > Open and File > Import 3 ways: individual files, Open all, and Import all. No problems at all. 

It's been a 2.5 months since Michael's comment, with no follow on. I suggest we consider it a non-P2, i.e., not a gate for Audacity 2.0.

I have forwarded a number of crash reports on OS X to Michael since his last comment. I gather they don't help pinpoint the problem. 

Ratio of failure is usually 100% while it is going on, from the reports I have seen. Reboot is fairly likely to cure it for a time. 

Personally this is one issue I have not seen since May on Windows 7 or XP.  

Reports since April 1st 2010 in 1.3.12:

32 on OS X  (8 x 10.4 or 10.5 Intel or PPC) (16 x 10.6.2/3) (8 x 10.6.4) 
3 on Windows (1 x Vista  2 x Win 7) (one of those Win 7 is me)

Usually these are AIFFs made by Audacity on Mac, but not absolutely always. The information I have is that the crash seems to occur after a subliminal copy-in progress bar or OD hatching is seen.  

As for "I suggest we consider it a non-P2, i.e., not a gate for Audacity 2.0" the "not a gate for 2.0" is long since agreed with me. P2/P3 isn't. It's been suggested by others that the standards for a first "stable" could be somewhat lower (c.f. 1.2.0) so why not reflect that in the ratings and allow moonphase P2s in early "stables"? Seems to reflect the current reality to me.

If this happens on the mac it would be very helpful if the users could post a stack trace, by going to the activity monitor and clicking sample while Audacity is selected.
Even in release mode we leave the symbol names in.

I just checked in r10547, which may fix a deadlock condition.  Gale, if you can still replicate, please test.

Note that there are two types of bugs.  One is the OD hang, where the GUI still functions, but the progress never moves.  Another is the type where the program crashes outright (most of the mac related ones were these type.)  r10536 (July 19) may fix those.

I will test against r10547 for OD hangs. However none of those reports above since April were presented as OD hangs. 

Also some of those crashes were when copying in (I asked some people who were crashing with OD to change to copy in and they still got crashes). I'll try and  find people who I know were crashing with OD and see if they can try SVN for the r10536 fix.

Can you (Michael) also post a 44100 16-bit and 44100 24-bit AIFF and WAV made by Audacity on a Mac - those may be useful for further testing.

Given crashing is reported when copying in (see previous comment) I'm not clear how a "devel-fix made" can be entered for the whole bug.

r10536 was "Log: Fix missing lock mutex in main OD loop (!)
This will fix the OD bug where some tasks never start on faster computers  
that caused the race condition."

Even if the might fix OD crashes (?) does it fix copy-in crashes?

Re-opening. Confused by comments and thought both issues had been addressed.

Gale thinks this may be related to bug 35, so when Michael makes further changes to fix this, check whether they fix bug 35.

(In reply to comment #11)

Yeah, maybe bug 35 is related to bug 35!

Sorry, I meant bug 210. Too much copy/paste.

Looked at this again, but still can't replicate the bug.

Here's a link to a 24 bit aiff as requested; apologies for the delay.
http://michaelchinen.com/mike/misc/audmac24.aiff

Gale, I reviewed the reports you sent (about 5).  Could you please continue forward them to me as they come in, or is there a way for us to view them without forwarding?

(In reply to comment #13)
> I reviewed the reports you sent (about 5).  Could you please continue
> forward them to me as they come in, or is there a way for us to view them
> without forwarding?

I can forward them to you. You could see some by asking Vaughan to add you to the addresses to which feedback@ forwards, but then you would also see a lot of tech support requests and spam you could perhaps do without. Some reports come direct to me so I can only forward those. 

I have only seen seven reports of WAV/AIFF import crashes since August (three on Windows, two Linux, two Mac). I deduce that instability in (or interactions with) early 10.6.4 was bumping up the tally of reports. However I don't have any example files or crash dumps from those seven reports I can give you. All I do know is that two of the reports were copying in WAV files, so I still don't think OD is behind the problem.

(In reply to comment #14)
There have been three reports I've seen since Comment 14 of WAV/AIFF crashes on OS X and Windows Vista/7 in 1.3.13 alpha. sadly I don't have a file to offer or a crash report. In two cases the problem was with any file they tried to import but the issue went away after reboot.

Please be aware of Bug 238 where libsndfile is ignoring sample offsets in the SSND chunk of AIFF files. I doubt this is relevant to stability. Typically the WAVs/AIFFs reported in this bug are those produced by Audacity itself, so if Bug 35 is relevant those files must have been exported from CD tracks imported on Mac.

(In reply to comment #16)

Looks to me like this bug has been changed from "moon phase" to "comet return". How about lowering its priority?

1) Is a more accurate title now "Occasional crash with non-OD import of WAV and AIFF"?  For me it is relevant that it is a crash, not a hang, not a corruption of the audio.  Those would be different bugs reports.

2) Three reports in about 20 days on 1.3.13 alpha is a worryingly high number of reports - given many people don't report bugs.  My impression is that this is a regression over what we used to have in 1.2.6 - or are we just better at getting reports than we used to be?  If the bug report levels scale proportionally as we ramp up on use, then we cannot demote this from a P2.


It is sounding like this bug report originally was catching multiple bugs -  because Michael made some clear OD fixes, but some bug(s) remain.


The factors that are most relevant to developers about the three reports are

OD or non OD; If OD, was there active user interaction or did the user just wait; WAV or AIFF; Copy-in or reference; Platform;

(In reply to comment #18)
> Three reports in about 20 days on 1.3.13 alpha
Where are these reports? If they on the Forum or -devel please give the URL. I have seen several uselessly vague reports on feedback@ which are not from 1.3.13 alpha but (possibly) 1.3.12. In so far as I could guess, I would assume them to be most likely Bug 137 (definitely in one case).  

Whatever your three reports are, I have received five reports since October ( 1.3.12 in 2 cases and 1.3.13 in 3 cases) that would seem to be this bug. They are from all three platforms, both OD and not. The common feature (four times out of five where the reporter is sure) is that Audacity exported these 16-bit PCM files originally. I have one example file from these reports, but I see little point submitting it because it has been tested on all three platforms in HEAD and doesn't repeatedly crash with OD or copy-in. Nor did it crash for the complainant once he rebooted his Mac.    

I would say the report levels on this bug have not changed since it was opened. 

Yes it is a regression on 1.2.5/6 - the "stable" does not have this problem to the best of my belief. 

Need more input from James.

>> Three reports in about 20 days on 1.3.13 alpha
>Where are these reports?
I'm referring to the three reports you mention in your comment 15!

That the files were exported from Audacity (4 times out of 5, possibly 5 times out of five) could be highly relevant, especially as the files themselves do not appear to be corrupt.

That would tend to suggest that the 16-bit export process is corrupting some data structure that then bites us later when we import.  It would be data used in export/import code but not elsewhere.  Needn't actually be the import export process itself - could even be something related to filename selection, bit-rate and format selection dialogs.

(In reply to comment #20)
> I'm referring to the three reports you mention in your comment 15!
I would not have guessed that without any reference, but in that case definitely only 5 reports (I've seen) since comment 15. Difficult to tell, but the problem does not seem to be getting worse, and "something" we've done may have improved it. We were getting 15 reports per month of this between April and July 2010.

To me, it's also significant that once the issue starts, it tends to continue until reboot (or sometimes restart of Audacity) with any WAV or AIFF (not necessarily ones written by Audacity). A glance at my notes shows about 15 people who say this (out of 70 odd). 

The smaller number of reports do now suggest to me the bug could be demoted (at a pinch). Against, once this problem starts, there are a number of suggestions that Audacity is pretty generally destabilised - if you generate a tone and play it, Audacity can just disappear (without any imported files present any longer).

It's worth flagging up that we aren't running the latest libsndfile in Audacity SVN by some margin, so we are missing out on some potential fixes there. The reason we aren't using the latest release is because upstream has stopped supporting builds with Visual Studio (any version), so we will need to create a substantial patch (which upstream won't accept), as well as do quite a lot of regression testing of our build (there is a test suite, but it's unix-centric).

I suspect that this is completely irrelevant however, and that the comments about in-memory corruption are likely correct.

I had a repeatable-from-clean-start crash on wav import recently, but it went away when I cleared my preferences - I think I had set up custom import via FFmpeg, then didn't have an FFmpeg library available when I tried to open the file. As I couldn't get back to the same place after clearing the preferences, I didn't report it at the time.

Assuming we are right about in-memory, would using a debug memory allocator, or some sort of stack corruption warning system be useful? The aim would be to create a debug build that failed much nearer the cause of the corruption (ideally at it). I know GCC has a bunch of options for this, but I've never used any of them.

(In reply to comment #23)
Everything here points to memory corruption to me, except it's unclear why only (Audacity) WAV or AIFFs start the problem. Not one of the 70-odd reports mention other formats. 

Although .cfg was relevant to some specific issues that Michael fixed, on the basis of reports since then, I think we can discount either .cfg settings or particular importers as a factor. 

Two of the five most recent reports are from people who find this issue semi-repeatable (i.e. it will happen every month or two) but other people don't see it at all (I have not, since Michael's fixes).

Is there a pattern about when in the import process the crash happens?

(In reply to comment #25)
> Is there a pattern about when in the import process the crash happens?
I don't have much information on that except for comment 5 where it says "the crash seems to occur after a subliminal copy-in progress bar or OD hatching is seen". Since I wrote that one person OD-importing a 90 minute WAV seemed to confirm that because he saw the entire "import" progress complete but then the crash occurred as the OD waveform started to be drawn. But as noted, if they restart after the crash and do pretty much anything in Audacity, they could then crash. 

I think you have seen crash reports from the time there were a lot of reports of this on OS X 10.6.4 and felt they did not reveal much.     

Anyone object to demoting this to P3? I'm sorry for the people that are more often affected but there seem to be really very few now. A number who are/were more commonly affected had "Audio Cache" on. One who had the problem when he had cache on did not have it again since he turned it off (he had 2 GB RAM on Win 7 x64).

(In reply to comment #26)
Since my last post, one report on Mac 10.6.6 of WAV import crashes until reboot, with OD set (crash reports not kept).    

One report on the Forum:
http://forum.audacityteam.org/viewtopic.php?f=17&t=46225&p=134173#p134173

Intel Mac 10.5.8. Audacity was hanging on launch due to VST or (too many) AU effects. WAVs were crashing repeatedly on import.  

"Audacity bouncing for a while whilst displaying "not responding" before loading up after a considerable amount of time. After loading up it crashed again when importing 3 .wavs

I waited for audacity to load up then I selected the safer import method whilst unchecking ALL the boxes in the "effects" panel. That solved everything. The import problem and the slow start up."

I've asked a few questions in the above topic - that is, after reboot, can the crashes be repeated if effects and/or OD are turned on again?

(In reply to comment #26)
> Anyone object to demoting this to P3?

I have had a read through this tonight and see no reason not to demote it.  All attempts to reproduce have failed here and elsewhere, and it appears that related reports have dried up.  I say mark as 'fixed' and see if it comes up again from a reliable source.

(In reply to comment #28)

+1

As per Gale's comment#26 

"> Anyone object to demoting this to P3?"

And Martyn and Vaughan's responses, have demoted to P3.  [Runs counter to rule that regressions are P2 or higher].

Also changed platform from PC to Mac, since the recent reports are (intel) Mac based.

(In reply to comment #30)
> Also changed platform from PC to Mac, since the recent reports are (intel)
> Mac based.
As per my comment 19, the (now 6) reports since October that really are this bug 
were on all three platforms (and I know audio cache was not on in most of those). So I have reverted the OS to "all" for now, even though I think more could occur on Mac than elsewhere. 

Could it be an Intel thing? I don't usually have that info, but all of the reports in the last 6 months (after those OS X 10.6.x crashes stopped happening)  and where the processor is stated, are on Intel.

(In reply to comment #31)

Another five reports since April 2011, all on OS X 10.6 (so Intel), including recent one on 1.3.13. In the three cases where I know details, two users were "copying in" and one "reading directly", and reboot fixed the problem. 

So still no real evidence that reading directly triggers this.

DEMOTED TO P5. 

I believe this bug is not occurring at the moment. It will be closed if this continues to be the case.

(In reply to Gale Andrews from comment #33)
This has not recurred since Gales las writing Comment #33

Accordingly I am going to close this bug as RESOLVED