Jimmy et al: Is there a naming pattern/trick that will always work? For 
example, if I just suffix the X!Tandem filename with say the characters 
"yyy" or "xml" or if I prefix it in some similar fashion, will that be a 
workaround for now?

On Sunday, 2 September 2012 12:56:49 UTC-4, Gautam Saxena wrote:
>
> I have bad news to report: gzipping the files sometimes fixes problems, 
> and sometimes not. In fact, we just ran some 1216 files through X!Tandem, 
> and 585 failed with this same "null pointer exception", so it looks like 
> one would tryly need to figure out what's going on with the program and 
> it's parsing of the name....Will provide more of an update tonight if I get 
> a chance....
>
> On Saturday, 25 August 2012 13:10:50 UTC-4, Gautam Saxena wrote:
>>
>> Gziping the file seems to have solved the problem for those 35 files. 
>> But, 1) I don't know if it always solves the problem; 2) it causes other 
>> problems: specifically, the resultant pep.xml file now references within 
>> itself the xtandem file with the "gz" extension, and so at least one 
>> downstream program, namely LIBRA, now errors out because it's looking for 
>> an mzXML file that is named with a ".gz.mzXML" extension. Here's a sample 
>> error from Libra:
>>
>> Failed to open input file 
>>> '/usr/ia_working_dir/DASH/DASH_Server/JHU_NHLBI/Users/
>>> gsaxena_i-a-inc.com/Workflow_Outputs/Centroided_-_Cys_TMT_Zero_0824_50ppm/zTvL-120625_1CPr_CysTMT0
>>> .gz.mzXML'.
>>
>>
>> And, less importantly, gziping consumes a little CPU, which adds up if we 
>> have 1000 or so MS files for a given project.
>>
>> So, it would be very beneficial if this bug were to be resolved. In case 
>> it helps, here's something else I noticed:
>>
>>
>>    1. In once project in which we had 1216 MS files, 1201 of those files 
>>    correctly ran though tandem2xml. However, 15 failed with the same error 
>>    message as indicated previously. The input file to tandem2xml was in a 
>>    different directory that I referenced with a fully qualified path name, 
>> as 
>>    in:
>>
>> cd /usr/my_working_dir
>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_programs/tpp/bin/Tandem2XML
>>  
>> /usr/some_dir/another_dir/zz85-control-8-003-9 
>> 0Cw6-zz85-control-8-003-9.pep.xml 
>>
>> I solved the problem by creating symbolic link called 
>> " zz85-control-8-003-9"  in the "/usr/my_working_dir" that pointed to  
>> /usr/some_dir/another_dir/zz85-control-8-003-9 and then tandem2xml 
>> magically worked.
>>
>> Also, I'm not sure if this is an additional wrinkle, but my X!Tandem 
>> files have NO extension. (I needed to do this to support LIBRA properly in 
>> my scenario.)
>>
>>
>> On Friday, 24 August 2012 12:16:52 UTC-4, Dave Trudgian wrote:
>>>
>>> That's the same problem I saw then. I'll try and have a look at this 
>>> properly on the weekend, or failing that on Monday / Tuesday. I started to 
>>> look through it before, but the input handling is so complex an hour wasn't 
>>> enough to understand it. 
>>>
>>> We come across this issue a lot now, due to the way our 
>>> mass-spectrometrists commonly name files. 
>>>
>>> DT 
>>>
>>> -----Original Message----- 
>>> From: [email protected] [mailto:[email protected]] 
>>> On Behalf Of Jimmy Eng 
>>> Sent: Friday, August 24, 2012 11:11 AM 
>>> To: [email protected] 
>>> Subject: Re: [spctools-discuss] Re: tandem2xml gives "invalid pointer" 
>>> error on linux 
>>>
>>> FWIW, just doing something as simple as changing the name from 
>>> "zz85-control-8-003-9" to "zz85-control-8-003-9y" allows the conversion to 
>>> go through fine.  Hopefully someone with time will look at the convoluted 
>>> input handling in Tandem2XML as the logic being used to parse input file 
>>> name and recognize file extensions is horribly broken. 
>>>
>>> On Fri, Aug 24, 2012 at 7:56 AM, Dave Trudgian <
>>> [email protected]> wrote: 
>>> > Gautum, 
>>> > 
>>> > Maybe this is related to the problem I observed that seems filename 
>>> > dependent: 
>>> > 
>>> > https://groups.google.com/d/topic/spctools-discuss/lp9qde0b2OU/discuss 
>>> > ion 
>>> > 
>>> > If you rename the files do they process correctly? Is there anything 
>>> > common about the filenames of the 35 that don't work? If you run 
>>> > Tandem2XML against the gzipped file does it work? 
>>> > 
>>> > DT 
>>> > 
>>> > If you try to run the command with the 
>>> > 
>>> > 
>>> > On Friday, August 24, 2012 9:39:21 AM UTC-5, Gautam Saxena wrote: 
>>> >> 
>>> >> I have TPP v4.5 RAPTURE rev 2, Build 201208061232 (linux) on Centos 
>>> >> 6.3 (all up to date, 64 bit) installed and pretty much working. For 
>>> >> one project, though, we ran tandem2xml on 632 X!Tandem files. For 597 
>>> >> of such files, it converted fine. For 35 though, we got the "invalid 
>>> >> pointer" error as 
>>> >> follows: 
>>> >> 
>>> >>> *** glibc detected *** 
>>> >>> 
>>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_programs/tpp/bin/Tandem2XML:
>>>  
>>>
>>> >>> free(): invalid pointer: 0x00000000016fba40 *** ======= Backtrace: 
>>> >>> ========= /lib64/libc.so.6[0x3e316753c6] 
>>> >>> /usr/lib64/libstdc++.so.6(_ZNSsD1Ev+0x39)[0x3e34a9d4a9] 
>>> >>> 
>>> >>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_progra 
>>> >>> ms/tpp/bin/Tandem2XML[0x413821] 
>>> >>> 
>>> >>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_progra 
>>> >>> ms/tpp/bin/Tandem2XML[0x405f4e] 
>>> >>> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3e3161ecdd] 
>>> >>> 
>>> >>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_progra 
>>> >>> ms/tpp/bin/Tandem2XML[0x405c89] 
>>> >>> ======= Memory map: ======== 
>>> >>> 00400000-00469000 r-xp 00000000 00:18 32638052 
>>> >>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_progra 
>>> >>> ms/tpp/bin/Tandem2XML 
>>> >>> 00669000-0066b000 rw-p 00069000 00:18 32638052 
>>> >>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_progra 
>>> >>> ms/tpp/bin/Tandem2XML 
>>> >>> 0066b000-0066d000 rw-p 00000000 00:00 0 
>>> >>> 016f8000-01719000 rw-p 00000000 00:00 0 [heap] 
>>> >>> 3e31200000-3e31220000 r-xp 00000000 fd:00 6809 /lib64/ld-2.12.so 
>>> >>> 3e3141f000-3e31420000 r--p 0001f000 fd:00 6809 /lib64/ld-2.12.so 
>>> >>> 3e31420000-3e31421000 rw-p 00020000 fd:00 6809 /lib64/ld-2.12.so 
>>> >>> 3e31421000-3e31422000 rw-p 00000000 00:00 0 
>>> >>> 3e31600000-3e31789000 r-xp 00000000 fd:00 6810 /lib64/libc-2.12.so 
>>> >>> 3e31789000-3e31988000 ---p 00189000 fd:00 6810 /lib64/libc-2.12.so 
>>> >>> 3e31988000-3e3198c000 r--p 00188000 fd:00 6810 /lib64/libc-2.12.so 
>>> >>> 3e3198c000-3e3198d000 rw-p 0018c000 fd:00 6810 /lib64/libc-2.12.so 
>>> >>> 3e3198d000-3e31992000 rw-p 00000000 00:00 0 
>>> >>> 3e31e00000-3e31e17000 r-xp 00000000 fd:00 6811 
>>> >>> /lib64/libpthread-2.12.so 
>>> >>> 3e31e17000-3e32017000 ---p 00017000 fd:00 6811 
>>> >>> /lib64/libpthread-2.12.so 
>>> >>> 3e32017000-3e32018000 r--p 00017000 fd:00 6811 
>>> >>> /lib64/libpthread-2.12.so 
>>> >>> 3e32018000-3e32019000 rw-p 00018000 fd:00 6811 
>>> >>> /lib64/libpthread-2.12.so 
>>> >>> 3e32019000-3e3201d000 rw-p 00000000 00:00 0 
>>> >>> 3e32200000-3e32215000 r-xp 00000000 fd:00 48060 
>>> >>> /lib64/libz.so.1.2.3 
>>> >>> 3e32215000-3e32414000 ---p 00015000 fd:00 48060 
>>> >>> /lib64/libz.so.1.2.3 
>>> >>> 3e32414000-3e32415000 r--p 00014000 fd:00 48060 
>>> >>> /lib64/libz.so.1.2.3 
>>> >>> 3e32415000-3e32416000 rw-p 00015000 fd:00 48060 
>>> >>> /lib64/libz.so.1.2.3 
>>> >>> 3e32600000-3e32683000 r-xp 00000000 fd:00 4968 /lib64/libm-2.12.so 
>>> >>> 3e32683000-3e32882000 ---p 00083000 fd:00 4968 /lib64/libm-2.12.so 
>>> >>> 3e32882000-3e32883000 r--p 00082000 fd:00 4968 /lib64/libm-2.12.so 
>>> >>> 3e32883000-3e32884000 rw-p 00083000 fd:00 4968 /lib64/libm-2.12.so 
>>> >>> 3e33a00000-3e33a10000 r-xp 00000000 fd:00 6655 
>>> >>> /lib64/libbz2.so.1.0.4 
>>> >>> 3e33a10000-3e33c0f000 ---p 00010000 fd:00 6655 
>>> >>> /lib64/libbz2.so.1.0.4 
>>> >>> 3e33c0f000-3e33c11000 rw-p 0000f000 fd:00 6655 
>>> >>> /lib64/libbz2.so.1.0.4 
>>> >>> 3e34200000-3e34216000 r-xp 00000000 fd:00 6814 
>>> >>> /lib64/libgcc_s-4.4.6-20120305.so.1 
>>> >>> 3e34216000-3e34415000 ---p 00016000 fd:00 6814 
>>> >>> /lib64/libgcc_s-4.4.6-20120305.so.1 
>>> >>> 3e34415000-3e34416000 rw-p 00015000 fd:00 6814 
>>> >>> /lib64/libgcc_s-4.4.6-20120305.so.1 
>>> >>> 3e34a00000-3e34ae8000 r-xp 00000000 fd:00 6815 
>>> >>> /usr/lib64/libstdc++.so.6.0.13 
>>> >>> 3e34ae8000-3e34ce8000 ---p 000e8000 fd:00 6815 
>>> >>> /usr/lib64/libstdc++.so.6.0.13 
>>> >>> 3e34ce8000-3e34cef000 r--p 000e8000 fd:00 6815 
>>> >>> /usr/lib64/libstdc++.so.6.0.13 
>>> >>> 3e34cef000-3e34cf1000 rw-p 000ef000 fd:00 6815 
>>> >>> /usr/lib64/libstdc++.so.6.0.13 
>>> >>> 3e34cf1000-3e34d06000 rw-p 00000000 00:00 0 
>>> >>> 2adaee375000-2adaee376000 rw-p 00000000 00:00 0 
>>> >>> 2adaee382000-2adaee389000 rw-p 00000000 00:00 0 
>>> >>> 7fffc87d1000-7fffc87e6000 rw-p 00000000 00:00 0 [stack] 
>>> >>> 7fffc87ff000-7fffc8800000 r-xp 00000000 00:00 0 [vdso] 
>>> >>> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] 
>>> >> 
>>> >> 
>>> >> 
>>> >> The program was run as follows: 
>>> >> 
>>> >>> 
>>> >>> /usr/ia_working_dir/DASH/DASH_Server/IA_Common/programs/linux_progra 
>>> >>> ms/tpp/bin/Tandem2XML 
>>> >>> zz85-control-8-003-9 0Cw6-zz85-control-8-003-9.pep.xml 
>>> >> 
>>> >> 
>>> >>  I have attached a zipped version of the input file, 
>>> zz85-control-8-003-9. 
>>> >> (Note, you'll need to unzip and then rename the file to get rid of 
>>> >> the ".temp" suffix; then, you should be able to run the above command 
>>> >> exactly as 
>>> >> is.) 
>>> >> 
>>> >> Any clues? 
>>> >> 
>>> >> Thanks in advance. 
>>> >> 
>>> >> Regards, 
>>> >> Gautam 
>>> >> 
>>> >> 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> > Groups "spctools-discuss" group. 
>>> > To view this discussion on the web visit 
>>> > https://groups.google.com/d/msg/spctools-discuss/-/9ASFYEooFCMJ. 
>>> > 
>>> > 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. 
>>>
>>> -- 
>>> 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. 
>>>
>>>
>>> ________________________________ 
>>>
>>> UT Southwestern Medical Center 
>>> The future of medicine, today. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"spctools-discuss" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/spctools-discuss/-/DMC_xeFrLWgJ.
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.

Reply via email to