Hi all!<br>
<br>
Ok, got what should be done. But now I have a (big) question: this code
compiles properly with gcc. Ok, maybe that means difference of
tolerance between different compilers. But the code also compiles with
intel on intel machines, and seems to work properly on older amd
machines (not quite sure if they need to be so old that there is no SSE
even).<br>
<br>
Is there any possibility the compiler is messing out with us somehow?
Cause the same machine, different compilers, would mean bogus or
something comiler, but same compiler, differente machines (or different
cpu manufacturer?), seems to mean evil economics practices. :(<br>
<br>
Is there any chance this "suppositions" could be right? And so, it
would be useless to try to crack our heads on "debugging" for one
specific compiler the more optimized code of the world?<br>
<br>
Thanks for everything in advance.<br>
<br>
Jones<br><br><div><span class="gmail_quote">On 5/31/06, <b class="gmail_sendername">David Mathog</b> <<a href="mailto:mathog@caltech.edu">mathog@caltech.edu</a>> wrote:</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Program received signal SIGSEGV, Segmentation fault.<br>> 0x00002aaaab15a88c in __find_specmb () from /lib64/tls/libc.so.6
<br>> (gdb) where<br>> #0 0x00002aaaab15a88c in __find_specmb () from /lib64/tls/libc.so.6<br>> #1 0x00002aaaab140e6f in vfprintf () from /lib64/tls/libc.so.6<br>> #2 0x00002aaaab15e2a9 in vsprintf () from /lib64/tls/libc.so.6
<br>> #3 0x00002aaaab149568 in sprintf () from /lib64/tls/libc.so.6<br>> #4 0x000000000040248b in mknb_code (format=0x40cd2e "s") at<br>> mknb_metacode.c:282<br><br>This says that there's a call to sprintf() at mknb_metacode.c line
<br>282. Just before that call check all the parameters that will<br>be passed to sprintf. You can do that in the debugger, but you<br>might find it easier to just put a bunch of printf's in at that point.<br>Looks like there's a a bad pointer in there somewhere. Once you
<br>figure out which variable is bogus trace back up through the following<br>code with the debugger (or more printf's)<br><br>> #5 0x0000000000401aaf in mknb_declare_real (name=0x7fffffffd0d0<br>> "ix1,iy1,iz1,fix1,fiy1,fiz1") at mknb_metacode.c:104
<br>> #6 0x0000000000403e62 in mknb_declare_variables () at<br>> mknb_declarations.c:258<br>> #7 0x0000000000400fef in mknb_write_function () at mknb.c:154<br>> #8 0x00000000004017cf in main (argc=1, argv=0x7fffffffd628) at
mknb.c:348<br><br>until you find out where things have gone wrong.<br><br>Regards,<br><br><br>David Mathog<br><a href="mailto:mathog@caltech.edu">mathog@caltech.edu</a><br>Manager, Sequence Analysis Facility, Biology Division, Caltech
<br>
</blockquote></div>