Segment violation in atomic_test_and_set

[michael.weirauch]

hrev36193 gcc4h2 on Thinkpad T500

Running svn (or sed)

[tcsetpgrp failed in terminal_inferior: Invalid Argument]
[Switching to team /boot/common/bin/svn (2091) thread svn (2091)]
0x008ab158 in atomic_test_and_set () from /boot/system/lib/gcc2/libroot.so
(gdb) bt
#0  0x008ab158 in atomic_test_and_set () from /boot/system/lib/gcc2/libroot.so
#1  0x0091aba1 in BPrivate::hoardLock () from /boot/system/lib/gcc2/libroot.so
#2  0x0091e98e in BPrivate::threadHeap::malloc ()
   from /boot/system/lib/gcc2/libroot.so
#3  0x0091f6ec in malloc () from /boot/system/lib/gcc2/libroot.so
#4  0x00918ff9 in add_fork_hook () from /boot/system/lib/gcc2/libroot.so
#5  0x0091913c in __register_atfork () from /boot/system/lib/gcc2/libroot.so
#6  0x0090b5dc in atfork () from /boot/system/lib/gcc2/libroot.so
#7  0x0090bcd4 in __init_env () from /boot/system/lib/gcc2/libroot.so
#8  0x0089d591 in initialize_before () from /boot/system/lib/gcc2/libroot.so
#9  0x0089d40e in _init_before () from /boot/system/lib/gcc2/libroot.so
#10 0x0089d2eb in _init () from /boot/system/lib/gcc2/libroot.so
#11 0x001005b2 in _ZL17init_dependenciesP7image_tb ()
   from /boot/system/runtime_loader
#12 0x00100e5c in load_program () from /boot/system/runtime_loader
#13 0x00105325 in runtime_loader () from /boot/system/runtime_loader
#14 0x7ffeefec in ?? ()

[michael.weirauch]

Issue was actually seen on a fresh hrev36163. (reported revision was wrong) (Still not able to edit my own bugreports.)

With a fresh hrev36189 the issue is gone. Wondering...

Can be closed. Sorry for the noise.

[stippi]

And before (with hrev36163) it was 100% repeatable?

[michael.weirauch]

Hi Stephan,

I just retried with hrev36163 and couldn't reproduce the issues. Must have been a build issue then. (Stale generated objects? No idea.)

So I'd propose this one to be closed invalid.

[stippi]

I've ran into the issue myself this morning, with an "update-all" build. The exact same revision installed as fresh image (without passing "update-all", but without cleaning the object folder either) would run fine again. Since Ingo already said "update-all" is a hack he doesn't feel like improving, I am marking this as invalid. Otherwise it would be a buildsystem bug, I suppose.

[michael.weirauch]

Just for the record... I am pretty sure I did use a "full-build" for that revision. Otherwise I wouldn't have dared to report a bug as I know there are issues with "update-all-builds". But I for sure did some "update-all-builds" to that installation beforehand. So I can only wildly guess, that there might have been some inconsistency in the build-dirs leading to a faulty "full-build".