Opened at 2010-10-17T23:07:35Z
Closed at 2026-09-26T02:20:24Z
#683 closed fixme (wontfix)
Trap in shutdown -- maybe tempbuf overrun
| Reported by: | Ichthyostega | Owned by: | Christian Thäter |
|---|---|---|---|
| Priority: | normal | Milestone: | 0integration |
| Component: | lumieraVault | Keywords: | |
| Sub Tickets: | Parent Tickets: |
Description (last modified by )
We get an abort while in shutdown code, after running some of the tests.
*** glibc detected *** bin/test-config: free(): invalid next size (normal): 0x0000000000613dc0 *** Thread [1] (Suspended: Signal 'SIGABRT' received. Description: Aborted.) 8 raise() 0x00007ffff594fed5 7 abort() 0x00007ffff59513f3 6 <symbol is not available> 0x00007ffff598c408 5 <symbol is not available> 0x00007ffff59919a8 4 free() 0x00007ffff5993ab6 3 lumiera_free() src/lib/safeclib.h:83 0x00007ffff78989bc 2 lumiera_config_destroy() src/common/config.c:140 0x00007ffff7898936 1 main() tests/common/test-config.c:379 0x00000000004046f5
A small number of the vault/lib tests are affected, e.g. the example-plugin, or some config tests, e.g.
./test-config wordlist_add 'foo.bar' '' first second
Change history (7)
comment:2 by , at 2011-05-20T16:08:21Z
the exact location the error is triggered...
8 lumiera_tmpbuf_freeall() /mnt/Lager/heim/devel/lumi/src/lib/tmpbuf.c:75 0x00007ffff7b500d9 7 __cxa_finalize() 0x00007ffff56cad88 6 __do_global_dtors_aux() 0x00007ffff7b483b6 5 <symbol is not available> 0x00000000004014d0 4 <symbol is not available> 0x00007fffffffe510 3 _fini() 0x00007ffff7b9f8e1 2 <symbol is not available> 0x0000000000000016 1 <symbol is not available> 0x00007ffff7defd94
This means, it happens after the end of main(). Also, in the observerd cases, lumiera_config_destroy() was already invoked successfully. There is only one thread left, which now enters lumiera_tmpbuf_freeall()
void
lumiera_tmpbuf_freeall (void)
{
pthread_once (&lumiera_tmpbuf_tls_once, lumiera_tmpbuf_init);
struct lumiera_tmpbuf_struct* buf = pthread_getspecific (lumiera_tmpbuf_tls_key);
if (buf)
{
pthread_setspecific (lumiera_tmpbuf_tls_key, NULL);
for (int idx = 0; idx < LUMIERA_TMPBUF_NUM; ++idx)
lumiera_free (buf->big_buffers[idx]);
lumiera_free (buf);
}
}
Now
- buf->small_idx == 5
- all other indices are 0
- after the for-loop, the call to lumiera_free(buf) triggers the Alarm.
comment:3 by , at 2011-05-20T16:10:05Z
-- alternatively --
the error can also be produced with several other config tests, e.g. with test-config basic_set_get 'foo' '=bar'
The observed situation is similar, only the number of small_idx varies.
comment:4 by , at 2011-05-20T16:18:40Z
when we remove the atexit (lumiera_tmpbuf_freeall) (in tmpbuf.c, 63), then the Alarm is triggered from some other dtor or cleanup (in the observerd case from boost_regexp).
comment:5 by , at 2011-05-21T05:27:22Z
Note REVERT with 36cfaaa
For now I've swapped in the old tmpbuf implementation from July 2010 (at the state of commit bc989dab), to get rid of the broken build state.
comment:6 by , at 2022-10-21T21:09:09Z
| Description: | modified (diff) |
|---|---|
| Priority: | grave → normal |
comment:7 by , at 2026-09-26T02:20:24Z
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Since this ticket was opened, the Lumiera Architecture has evolved into a different direction. First and foremost, we do not treat "memory" as a generic resource — rather we classify into purpose and usage patterns. And we use dedicated allocation schemes for these. The idea of a tempbuf, were we just hope that some memory is there and do not care for precise control of the usage pattern, does not fit into this picture.
This is the deeper reason why this design was not further developed.
The related code is still in-tree, since it is used by facilities that are considered useful for the time being, but will be replaced by a different design eventually. The most prominent example here is the "Config System" ⟶ see #1224
See also
- #653
- my rationale for dropping the RfC DataBackend

In discussion on IRC, we suspected the changed Tempbuf implementation to be the cause.
The following experiments seem to support that theory:
src/lib/tmpbuf.hthe LUMIERA_TMPBUF_NUM 16 to -> 64, the error message changesLUMIERA_TMPBUF_SMALL 1048576then the error dissapearsLUMIERA_TMPBUF_SMALL sizeof(void*)results in "POSTCONDITION: config.c:311: thread_1: lumiera_config_setdefault: (item->delim) default must be a configentry with key=value or key<delegate syntax "