#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 Ichthyostega)

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:1 by Ichthyostega, at 2010-10-17T23:15:21Z

In discussion on IRC, we suspected the changed Tempbuf implementation to be the cause.

The following experiments seem to support that theory:

  • if we increase in src/lib/tmpbuf.h the LUMIERA_TMPBUF_NUM 16 to -> 64, the error message changes
  • if we set the LUMIERA_TMPBUF_SMALL 1048576 then the error dissapears
  • setting LUMIERA_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 "
  • commenting out the 'atexit' in tmpbuf.c has no effect

comment:2 by Ichthyostega, 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 Ichthyostega, 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 Ichthyostega, 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 Ichthyostega, 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 Ichthyostega, at 2022-10-21T21:09:09Z

Description: modified (diff)
Priority: grave → normal

comment:7 by Ichthyostega, 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

Note: See TracTickets for help on using tickets.