Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I have a build from the latest source, on a Ubuntu 64-bit build (12 CPUs, 20 GB RAM), which compiled and installed neatly. When I try to delete a base, it crashes with the following error:
jnash@heliosjr:~/analysis/Nitra$ gap5 S_Nitra_mirascaff2_out.0.g5d
Delete sequence/tag #1757704
tclsh: tg_cache.c:1544: cache_decr: Assertion `ci->updated == 0 || ci->hi->ref_count > 0' failed.
This happens on two separate computers which are configured fairly identically, and standardly, 100 km apart. These are the same computers on which tg_index hangs, as reported previously by me.
Is this deleting a base from a sequence or from the consensus (ie a "*")? The latter obviously does a lot more, including deleting from all sequences at that point and shuffling sequences / sequence-bins left by 1.
Either way, it shouldn't crash!
Oh I forgot to add, I *think* I may have found the cause of the tg_index hang, purely by accident! It's been patched in SVN: see the latest versions of tgap/tg_cache.c and tgap/tg_cache_item.h for details.
If it is this same bug, then I assume this means you're using a fairly recent version of gcc? (4.4 or newer I think). I'm not saying it's a fault in gcc, but rather some accidental and incorrect assumptions I was making which gcc changed behaviour with.
Yes, it is when I try to delete a base from the consensus. Usually when fixing a misassembly, or rationalizing the bases after a join.
Unfortunately the source downloaded from svn 20 minutes ago did not fix the problem. Here is the result of 'gcc -v'. It looks like it is new.
$ gcc -v
Using built-in specs.
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
(I meant the "tg_index hanging problem" in the previous message)
Let me add. For production, we are using the beta 8 version on a SUSE server. We use the i686 version to run gap5 (the x64 beta8 version does not allow searching of tags). We use the beta 8 x64 version to run tg_index (the i686 version doesn't work on 64 bit machines). Both the above behaviours can be replicated on two Ubuntu computers. This is not a problem as I have made the appropriate symlinks. So our production proof-readers are happy. (They would be happier using Windows but then the bioinformatics team gets cranky).
My own interest is to help you guys fix bugs. So please do not think I am whining when I call in bugs - I'm trying to provide feedback from the field.
We really appreciate the work that the Staden team puts into the programs…
Don't worry - I'm happy to receive bug reports. Well, not happy they exist, but happy they're reported! So thank you for that.
It's annoying that the bug I fixed apparently wasn't the same one you are still seeing in tg_index. Back to the drawing board again then. The bug was identical in behaviour, but apparently a different cause.
Coincidentally I'm also working on fixing issues with inserting bases to the consensus, which likely shares the same issues as deleting bases. It turns out certain combinations of complementing and joining contigs can get in a situation where it attempts to insert bases off the ends of sequences, typically causing a crash. I'm still rewriting that code, but hopefully this one will end up being the same as your bug.
Also thanks for the machine information. I'll try and get a copy of that specific gcc setup. The issues I found recently have been related to specific GCC versions and more aggressive optimisation techniques exposing bugs. (In one case mine, and perhaps in another case in GCC itself). So once I've got the insertion issue fixed I'll do some experiments with gcc 4.4.5.