Closed dertuxmalwieder closed 3 years ago
allinurl
commented
3 years ago Thanks for reporting this! Are you still able to reproduce it? If you are, it would be great if you could build with --enable-debug and run it through gdb to get the full back trace bt full.
Also were you restoring a persisted database when this occurred? Thanks
dertuxmalwieder
commented
3 years ago Yes, I was (after all, I try to use GoAccess in production), so I was suspecting that there could be a relation between the persisted database and the new format. Yes, I can reproduce it.
Here's bt full:
#0 0x00007ffff68a63d7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007ffff68a7ac8 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007ffff68e8f67 in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#3 0x00007ffff68f0c37 in malloc_consolidate () from /lib64/libc.so.6
No symbol table info available.
#4 0x00007ffff68f120e in _int_free () from /lib64/libc.so.6
No symbol table info available.
#5 0x00000000004195f0 in kh_destroy_iglp (h=0x4db650) at src/gkhash.h:85
No locals.
#6 0x000000000041ca15 in des_iglp (h=0x4db650, free_data=1 '\001') at src/gkhash.c:360
hash = 0x4db650
#7 0x000000000041cf84 in free_app_metrics (storage=0x4db400) at src/gkhash.c:549
i = 5
n = 7
mtrc = {metric = {storem = MTRC_HITS, dbm = MTRC_LAST_PARSE}, type = MTRC_TYPE_IGLP, alloc = 0x41c424 <new_iglp_ht>, des = 0x41c9e9 <des_iglp>, del = 0x0, hash = 0x4db650, filename = 0x455e17 "IGLP_LAST_PARSE.db"}
#8 0x0000000000423fb6 in free_igdb (hash=0x4db340, k=1) at src/gkhash.c:3632
db = 0x4db3e0
#9 0x000000000042404a in des_igdb (h=0x4db340) at src/gkhash.c:3649
k = 1
hash = 0x4db340
#10 0x000000000042408c in free_storage () at src/gkhash.c:3659
No locals.
#11 0x000000000042459c in house_keeping_holder () at src/goaccess.c:145
No locals.
#12 0x00000000004245b2 in house_keeping () at src/goaccess.c:153
No locals.
#13 0x00000000004246fe in cleanup (ret=0) at src/goaccess.c:216
No locals.
#14 0x000000000042848c in main (argc=137, argv=0x4cba60) at src/goaccess.c:1566
quit = 0
ret = 0Note that I cannot install the missing debug information on this system - it is my webspace and it is among the very few systems where I am not root... :-) anyway, as gkhash.c is involved, I could imagine that it is indeed related to the "old" database format.
allinurl
commented
3 years ago Thanks for sharing that. I think I know what's the issue, but can I ask you to please post how did you run goaccess + which options did you use?
dertuxmalwieder
commented
3 years ago I wrote a shell script that runs it for me every ten minutes (I have not figured out yet how the server version works and I'm not impatient enough to spend more time trying), but I am gradually progressing towards moving the command-line options to the configuration file:
$HOME/bin/goaccess --log-file=$HOME/logs/webserver/access_log --agent-list --persist --restore --db-path=$HOME/goaccess.db/ --ignore-referrer=*.REDACTED.de --ignore-referrer=REDACTED.de --real-os --output=$HOME/html/stats/index.html --hide-referrer=REDACTED.de --hide-referrer=*.REDACTED.de --config-file=$HOME/goaccess.conf > /dev/null 2>&1Other than that, my changes in the configuration file mostly involve the log format which is non-standard for the time being.
allinurl
commented
3 years ago Please rebase from https://github.com/allinurl/goaccess/commit/4da07c4f679775d540981db23e1654d5d6281242 and give it a shot again. Let me know how it goes, hopefully that addresses the issue. Thanks!
dertuxmalwieder
commented
3 years ago Looks good, no crash anymore. :-) Feel free to close this... for now.
allinurl
commented
3 years ago Awesome, glad to hear that :) and thanks for keeping up with the latest commits :+1:
After updating 3bce68e96b436eae5592d2b7f2234baab707e30a to 319b65a and installing the new version (
make clean ; make && make install) over the previous one, calling the binary panics, probably when storing the hash tables (because the output file is generated just well first):So now I wonder what could be the problem - can't the update handle existing database files or is the code broken? :-)
Going back to 3bce68e restores the functionality. I'll probably stick with it for a while.