 |
bactrace files are kind of useless, we need a proper stacktrace e.g. traceback file. You only get those when you have debug symbols and a debugger like gdb installed. |
|
|
I agree, but didn't know if bactrace file plus the log would give you any clues, such as if you have seen this before. I can provide a stacktrack and corefile after the holiday weekend. I may even try and debug it a bit. Thanks, Michael |
|
|
A sig 11 e.g. SEGV always needs a stacktrace as then you at least see any fishy arguments to functions and where it exactly crashes and exactly what call resulted in the SEGV in the debugger. So yes you might be able to answer the question yourself if you look under a debugger to the crash. If you have more info it might be something that is solvable easily or not who knows. A core is most of the times not to great as you need the exact same environment to be able to do something with the core e.g. same platform etc. But the stacktrace is most of the time a good starting point. |
|
|
I leave this on feedback until you have new input. |
|
|
Not to much inforation (gdb) bt #0 0x76ec182c in list_plugins(alist*, POOL_MEM&) () from /usr/lib/bareos/libbareos-15.2.3.so Backtrace stopped: Cannot access memory at address 0x392e |
|
|
More details: (gdb) bt #0 0x76ec1854 in list_plugins(alist*, POOL_MEM&) () from /usr/lib/bareos/libbareos-15.2.4.so 0000001 0x00027174 in list_status_header (sp=0x75cfeb80, sp@entry=0x75cfeb78) at status.c:443 0000002 0x00028b2c in output_status (devicenames=0x46e38 "DriveA", sp=0x75cfeb78, jcr=0x753008e0) at status.c:77 0000003 status_cmd (jcr=jcr@entry=0x753008e0) at status.c:973 0000004 0x0001ea64 in handle_director_connection (dir=dir@entry=0x63f08) at dir_cmd.c:307 0000005 0x000269e4 in handle_connection_request (arg=0x63f08) at socket_server.c:99 0000006 0x76ed19e4 in workq_server () from /usr/lib/bareos/libbareos-15.2.4.so 0000007 0x76eb8e8c in lmgr_thread_launcher () from /usr/lib/bareos/libbareos-15.2.4.so 0000008 0x76c24fac in start_thread () from /usr/lib/libpthread.so.0 0000009 0x76993cc0 in ?? () from /usr/lib/libc.so.6 |
|
|
Implemented quick fix @ https://github.com/bareos/bareos/pull/53 I admit I do not fully understand the code execution path, but this does seem to fix the issue. Let me know if you want me to do something else or test something. I do have the default plugin directory along with a single plugin in the directory: /usr/lib/bareos/plugins/autoxflate-sd.so |
|
|
Interesting. We recently changed this (and other places) similar in bareos-16.2 and master. This had been required for Fedora 24, because gcc >= 6. What compiler did you use? |
|
|
If your problem does only come the gcc (with optimization enabled), the commit https://github.com/bareos/bareos/commit/805800af8b88b07efe0748f9a7533af67095e85d should also be relevant. |
|
|
gcc (GCC) 6.1.1 20160501 I was going to try 16.2 but didn't want to upgrade since it wasn't released or considered stable yet. |
|
|
Sure, it makes sense to wait for the release. I'm optimistic, that we'll have a release candidate today. A proper fix for bareos-15.2 would include the patch above. However, as this might influence other things, we will not add it to bareos-15.2 I guess, the problem did only occur in this place of the code, because you're only the bareos-sd on the Raspberry? AFAIK a solution would be to compile it without optimization (-O0). |
|
|
I confirmed disabling optimizations fixes the problem. |
|
|
Also, yes I am running the bareos-sd on the raspberry. |
|
|
FYI: My director box has also moved to gcc6.1.1. I am now seeing this problem on directors too. |
|
|
This has been fixed on 16.2.4 rc1. |
|
|
Bareos 16.2.4 is released. Therefore changes to bareos 15.2 do not seam to be required. |
- Anonymous
