Hi Natalie, The leak is apparent in QStar WIFF files of any size. For a 30 minute BSA QC run (25 MB file size), peak memory usage reached 314 MB (to produce ~195 MB mzXML output), which doesn't seem reasonable. Do you have your own data files that you can debug with? If not, I can upload the BSA run to your FTP site (need the details).
The data I'm trying to analyze consists of 2 hour runs at about 500 MB each. mzWiff crashes about halfway through a data file, leaving a 1.3 GB (incomplete) mzXML file which ends at an elution time of about 60 minutes (when memory reaches slightly > 2 GB). I have tried older releases of the executable up to 4.0.0 and all behave the same. I am considering recompiling a 64-bit executable, or trying to locate the leak. I'll check out the code from SourceForge, but if you have additional instructions for setting up the VC project, please let me know. Thanks, Moyez On Mar 16, 1:41 pm, Natalie Tasman <[email protected]> wrote: > Hello Moyez, > > Thank you for the detailed bug report. I haven't heard of issues with > mzWiff. Thanks for the MSVC hint-- I'm pretty sure this is not turned > on yet, but actually probably shouldn't be necessary. I agree with > you that that much memory usage sounds like a memory leak. The > converters are designed to process data scan-by-scan with a relatively > low memory overhead. > > If you can upload a sample file we can take a look and see if we can > replicate behavior and then fix it. > > Thanks, > > Natalie > > > > On Mon, Mar 16, 2009 at 9:11 AM, Moe <[email protected]> wrote: > > > I'm trying to convert Analyst QStar Elite data acquired with Analyst > > QS 2.0, with mzWiff version 4.2.0(build Feb 19 2009 09:48:08), on > > Windows XP Pro SP3 and Windows Server 2003 R2 x64 Standard SP2. > > > There appears to be a memory leak causing process memory to accumulate > > to > 2GB, shortly after which the program crashes with error: > > > ERROR: COM error 80004005 while processing sample#2 > > INFO: error message: Unspecified error > > > This happens both on 32-bit XP and 64-bit Server 2003, both systems > > have > 4GB physical memory. The per-process addressable limit for a 32- > > bit process is 2GB unless compiled with the /LARGEADDRESSAWARE Visual C > > ++ linker flag. > > > Is anyone aware of this problem? Is this in fact a leak that can be > > avoided? > > > Thanks, > > Moyez- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
