Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetPrecursorInfoFromScanNum() problem with MSFileReader_3.1SP4_x64 #4

Open
pmrotem opened this issue Oct 11, 2018 · 10 comments
Open

GetPrecursorInfoFromScanNum() problem with MSFileReader_3.1SP4_x64 #4

pmrotem opened this issue Oct 11, 2018 · 10 comments
Labels
bug from Thermo This bug is from the underlying Thermo closesource C++ library, not the pymsfilereader bindings.

Comments

@pmrotem
Copy link

pmrotem commented Oct 11, 2018

Hi,

Thanks for the code you offer, i took it and added it to my project.
For some reason, now my script crashes every now and then.
I located the source of the crash to GetPrecursorInfoFromScanNum() function and apparently the script crashes when i tries to touch the VARIANT variable after calling the dll function.
The odd thing is that it happens once in a while, i can run it for an hour and it won't crash then run it again and it crashes on start.

Would really appreciate you help,
Rotem

@frallain
Copy link
Owner

frallain commented Oct 13, 2018 via email

@pmrotem
Copy link
Author

pmrotem commented Oct 15, 2018

i'm using MSFileReader_3.1SP4_x64.
will try another msfilereader.
thanks,
Rotem

@pmrotem
Copy link
Author

pmrotem commented Oct 15, 2018

Hi,

i tried 2 other versions, but the same crash still happens.
I'm using 64 bit thermo dll and python, maybe switching to 32bit can make a change?

Thanks,
Rote,

@pmrotem
Copy link
Author

pmrotem commented Oct 17, 2018

Hi,

Just to let you know, it seems that moving to python 3 32-bit and MSFileReader_3.0SP2.zip 32-bit seems to solve the problem, can't reproduce the crash i had.

Rotem

@frallain
Copy link
Owner

frallain commented Oct 17, 2018 via email

@pmrotem
Copy link
Author

pmrotem commented Oct 18, 2018

at first i used MSFileReader_3.1SP4_x64 and python 3.5 64-bit.
I tried using other versions of comtypes package, and other msfilereader versions, but only switching to 32-bit seems to solve the issue.

@frallain frallain reopened this Jul 19, 2019
@frallain
Copy link
Owner

@pmrotem Could you provide your rawfile so that I (or Thermo) can reproduce this bug?
It must be a regression bug introduced in version 3.1

@frallain frallain changed the title GetPrecursorInfoFromScanNum() problem GetPrecursorInfoFromScanNum() problem with MSFileReader_3.1SP4_x64 Jul 19, 2019
@frallain
Copy link
Owner

Also, have you been trying on the same OS? Which one?
Same version of comtypes? Which one?
Same version of python? Which one?
What are the combinations of MSFileReader-Python versions you tried?

@frallain frallain added the bug from Thermo This bug is from the underlying Thermo closesource C++ library, not the pymsfilereader bindings. label Jul 19, 2019
@pmrotem
Copy link
Author

pmrotem commented Jul 21, 2019

Hi,

It is been a long time since then but i'll try the best i can:
comtypes - i tried 1.1.7 and maybe some earlier versions
os - i tried win10 mostly, i think also tried win7. i encountered this bug on at least 2 different pc's.
python 3.6.* 32 bit and the 32 bit msfilereader dll i mentioned(which works), but just so you'll know i encountered a memory error with big files due to the 32bit python(the virtual addresses are much smaller)
python 3.6.* 64 bit and the msfilereader 64bit 2 dll's (i mentioned above).

i can check if i can upload the mzml, but to where (btw, i encountered this error with different files, not only one)? as i told you, this bug is a nasty one, it doesn't happen at the same time and at the same place.

Thanks alot, and i hope this issue will be resolved.
Rotem

@rexdwyer
Copy link

I'm having the same problem.... python 3.8 64-bit... windows 10
When I call getVersionNumber, I get "66". The size of the DLL file is 263,680 bytes. Maybe that tells you which version.
The queer thing is that it causes the program to crash with an Oracle error message, so it took me a heck of a long time to track this down.

ORA-24550: signal received: Unhandled exception: Code=c0000005 Flags=0

Encountered exception while getting args for function:0x00007FFCEEBAD4CC
kpedbg_dmp_stack()+350<-kpeDbgCrash()+123<-kpeDbgSignalHandler()+128<-skgesig_Win_UnhandledExceptionFilter()+164<-00007FFCEB1F6913<-00007FFCEEBAD504<-00007FFCEEB963A6<-00007FFCEEBA9FFD<-00007FFCEEB351C8<-00007FFCEEBA907E<-00007FFCB931F1A0<-00007FFCB9315171<-00007FFCB9318159<-00007FFCB9318910<-00007FFCB9437254<-00007FFCB9420192<-00007FFCB9436907<-00007FFCB9436E73<-00007FFCB9420192<-00007FFCB9436907<-00007FFCB9436E73<-00007FFCB9420192<-00007FFCB941FE1A<-00007FFCB943F2CB<-00007FFCB9423CFD`
```
I can't tell from the chain above whether a working version has been identified.
I'm sort of stuck until this is sorted out ☹️ So I will start trying different versions in the morning...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug from Thermo This bug is from the underlying Thermo closesource C++ library, not the pymsfilereader bindings.
Projects
None yet
Development

No branches or pull requests

3 participants