oned crashes on fresh start when using USER_HOOK
|Assignee:||Ruben S. Montero||% Done:|
|Category:||Core & System|
|Target version:||Release 4.0|
|Affected Versions:||OpenNebula 3.8|
When starting oned first time, with empty DB, there is a crash when oned.conf contains USER_HOOK on CREATE.
When USER_HOOK is commented in oned.conf, then there is no crash on first run and everything works OK, even when USER_HOOK ir readded.
It is probably related with initial oneadmin & serveradmin users addition on first time.
Backtrace is here:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5d72f64 in pthread_mutex_lock () from /lib/libpthread.so.0
#0 0x00007ffff5d72f64 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x0000000000495bde in MadManager::lock (this=0x0) at include/MadManager.h:131
#2 0x000000000049500c in MadManager::get (this=0x0, uid=0, name=..., value=...) at src/mad/MadManager.cc:189
#3 0x00000000004bc0a4 in HookManager::get (this=0x0) at include/HookManager.h:83
#4 0x00000000004e57c5 in AllocateRemoveHook::do_hook (this=0x787060, arg=0x788d30) at src/hm/Hook.cc:37
#5 0x000000000041192b in Hookable::do_hooks (this=0x78c1d8, arg=0x788d30, hook_mask=1) at include/Hook.h:247
#6 0x00000000004ab956 in PoolSQL::allocate (this=0x78c190, objsql=0x788d30, error_str=...) at src/pool/PoolSQL.cc:126
#7 0x000000000047970c in UserPool::allocate (this=0x78c190, oid=0x7fffffffddec, gid=0, uname=..., gname=..., password=..., auth=..., enabled=true, error_str=...) at src/um/UserPool.cc:297
#8 0x0000000000478f4d in UserPool (this=0x78c190, db=0x772150, __session_expiration_time=900, hook_mads=..., remotes_location=...) at src/um/UserPool.cc:180
#9 0x000000000040e421 in Nebula::start (this=0x7526e0) at src/nebula/Nebula.cc:327
#10 0x000000000040a676 in oned_main () at src/nebula/oned.cc:61
#11 0x000000000040a94b in main (argc=2, argv=0x7fffffffec88) at src/nebula/oned.cc:177
#1 Updated by Ruben S. Montero almost 8 years ago
- Status changed from New to Assigned
- Assignee set to Ruben S. Montero
- Target version set to Release 4.0
I can confirm this one. You are totally right, while bootstrapping the DB the HookManager is not started so we are trying to get a component that does not exist...
Thanks for reporting!