#677 Segfault in Upgrade menus on NetBSD

[Anonymous]

Hi,

I'm trying to get VegaStrike building via the pkgsrc framework. So far with a little tweaking it's building with SDL or Glut, with or without Ogre etc.

The only issue is that it segfaults a lot when in the upgrade menus; I was wondering if this was a familiar issue?

(a couple partial backtraces below)

#0 _M_erase_node (b=0xaf1fec70, p=0xabfdf810, this=<optimized out="">)
at /usr/include/g++/tr1/hashtable.h:954
#1 erase (it=<optimized out="">, this=<optimized out="">)
at /usr/include/g++/tr1/hashtable.h:1001
#2 SharedPool<std::string, StringpoolTraits="">::Reference::unref (
this=0xab77b4a8) at ./src/SharedPool.h:50
#3 0x0866c1ab in ~Reference (this=0xab77b4a8, in_chrg=<optimized out="">)
at ./src/SharedPool.h:94
#4 ~Cargo (this=0xab77b490, in_chrg=<optimized out="">)
at ./src/cmd/images.h:132
#5 ~CargoColor (this=0xab77b490, in_chrg=<optimized out="">)
at ./src/cmd/unit_generic.h:69
#6 _Destroy<CargoColor> (pointer=0xab77b490)
at /usr/include/g++/bits/stl_construct.h:89
#7 destroy<CargoColor*> (last=0xab77b4e0, first=0xab77b490)
at /usr/include/g++/bits/stl_construct.h:99
#8 _Destroy<CargoColor*> (last=0xab77b4e0, first=<optimized out="">)
at /usr/include/g++/bits/stl_construct.h:122
#9 _Destroy<CargoColor*, CargoColor=""> (last=0xab77b4e0,
first=<optimized out="">) at /usr/include/g++/bits/stl_construct.h:148
#10 ~vector (this=<optimized out="">, in_chrg=<optimized out="">)
at /usr/include/g++/bits/stl_vector.h:313
#11 ~TransactionList (this=0xacdea8a4, in_chrg=<optimized out="">)
at src/cmd/basecomputer.h:95
#12 BaseComputer::~BaseComputer (this=0xacdea880, __in_chrg=<optimized out="">)
at src/cmd/basecomputer.cpp:458

#0 _M_erase_node (b=0xaf2f4c70, p=0xab3f6980, this=<optimized out="">)
at /usr/include/g++/tr1/hashtable.h:954
#1 erase (it=<optimized out="">, this=<optimized out="">)
at /usr/include/g++/tr1/hashtable.h:1001
#2 SharedPool<std::string, StringpoolTraits="">::Reference::unref (
this=0xab2867c8) at ./src/SharedPool.h:50
#3 0x0868c05b in ~Reference (this=0xab2867c8, in_chrg=<optimized out="">)
at ./src/SharedPool.h:94
#4 ~Cargo (this=0xab2867b0, in_chrg=<optimized out="">)
at ./src/cmd/images.h:132
#5 ~CargoColor (this=0xab2867b0, in_chrg=<optimized out="">)
at ./src/cmd/unit_generic.h:69
#6 _Destroy<CargoColor> (pointer=0xab2867b0)
at /usr/include/g++/bits/stl_construct.h:89
#7 destroy<gnu_cxx::normal_iterator<CargoColor*, std::vector<CargoColor=""> > > (last=<optimized out="">, first=<optimized out="">)
at /usr/include/g++/bits/stl_construct.h:99
#8 _Destroy<gnu_cxx::normal_iterator<CargoColor*, std::vector<CargoColor=""> > > (last=<optimized out="">, first=<optimized out="">)
at /usr/include/g++/bits/stl_construct.h:122
#9 _Destroy<gnu_cxx::normal_iterator<CargoColor*, std::vector<CargoColor=""> >, CargoColor> (last=<optimized out="">, first=<optimized out="">)
at /usr/include/g++/bits/stl_construct.h:148
#10 std::vector<CargoColor, std::allocator<CargoColor=""> >::operator= (
this=0xab677c24, __x=...) at /usr/include/g++/bits/vector.tcc:176
#11 0x08673731 in operator= (this=<optimized out="">) at src/cmd/basecomputer.h:95
#12 BaseComputer::resetTransactionLists (this=0xab677c00)
at src/cmd/basecomputer.cpp:1641
#13 0x08688652 in BaseComputer::loadUpgradeControls (this=0xab677c00)
at src/cmd/basecomputer.cpp:3265

[Anonymous]

dear god the formatting

[Anonymous]

gdb backtrace attached

[Klauss++]

Could you do a build without optimizations and attach a similar backtrace?

There's lots of interesting info there that shows as "optimized out"

[Klauss++]

In any case, it sounds like a double-unref. Which sounds quite unlikely given the code.

Or maybe vsUMap maps to something whose end() iterator isn't preserved across rehashes.

Which version of which compiler are you using?

[Klauss++]

Workaround:

In src/SharedPool.h

Change

#define INITIAL_STRINGPOOL_SIZE (1<<15)

With

#define INITIAL_STRINGPOOL_SIZE (1<<17)

Or if you're still experiencing the issue:

#define INITIAL_STRINGPOOL_SIZE (1<<19)

The higher the number the more memory it will eat uselessly, but it shouldn't be a problem amount in any case.

[Anonymous]

I'm building with:

Using built-in specs.
COLLECT_GCC=gcc
Target: i486--netbsdelf
Configured with: /usr/src2/tools/gcc/../../external/gpl3/gcc/dist/configure --target=i486--netbsdelf --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb2 20111202' --enable-__cxa_atexit --with-arch=i486 --with-tune=nocona --with-mpc=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --with-mpfr=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --with-gmp=/var/obj/mknative/i386/usr/src2/destdir.i386/usr --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd5.99.56 --host=i486--netbsdelf
Thread model: posix
gcc version 4.5.3 (NetBSD nb2 20110806)

and using -O0 so I guess I will need to rebuild the userland and deps.

[Klauss++]

Weird that -O0 optimizes out stuff.

But in any case, I think my earlier post is on the money, especially noting the same was reported on windows.

I'm considering replacing the hash map with an rbtree. It would be bug-free at least, although a tad slower.

[Anonymous]

It's somewhat better; is it worth building from trunk instead? I wonder if anyone has been building it on FreeBSD lately, I'd love to pick their brains.

[Klauss++]

This particular issue hasn't been fixed in trunk yet. When I do, I think I'll switch to an rtbtree instead of resizing the hashmap. Stability trumps performance.

[Anonymous]

Also noticed that FreeBSD has the same sound issue as NetBSD. I'll keep poking at it and see what else I can come up with.

[logzero]

Afair unordered containers guarantee that references or pointers to key or data are only invalidated by erasing that element (ordered containers guarantee this for both iterators and references).

So replacing iterators by pointers to key-value pairs should fix the issue. The destructor would have to be adjusted to lookup the element by key to erase it when ref counter hits 0.