| T. Ribbrock wrote: |
|
I just ran into the following bug:
I have a logbook where entries have several attributes, among which several dates. All of these are set to "Type <attr> = date". If I use the "Select" action, tag several entries and subsequently chose "Edit", the values of all date attributes are wiped. All other attributes are kept at their original values, unless changed explicitly. For the date entries, the date choosers are shown (as when editing a single entry), but all set to blank.
Editing single entries works fine.
|
This problem has been fixed in revision 2.7.5-2143. Please upgrade. |
A statement like "core dumped" does not help much. Same with valgrind memory leaks. I need a full strack trace with all parameters when the segment violation occurs. The easiest is when you run elogd vom inside gdb, and once you get the signal, do a "where" to see th full stack trace.
As you can see from this forum, there is absolutely no crash when you upload any file, so it must have to do with your config file or anything whcih is special in yoru environment. We have to find what this is so that I can reproduce it here.
Stefan |
Thanks for further instructions here is full stack trace:
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
warning: 44 ./nptl/pthread_kill.c: No such file or directory
(gdb) where
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff764526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff76288ff in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff76297b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff77ce765 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132
#6 0x00007ffff7736c19 in __GI___fortify_fail (msg=msg@entry=0x7ffff77ce74c "buffer overflow detected") at ./debug/fortify_fail.c:24
#7 0x00007ffff77365d4 in __GI___chk_fail () at ./debug/chk_fail.c:28
#8 0x00007ffff7738019 in __strlcpy_chk (s1=<optimized out>, s2=<optimized out>, n=<optimized out>, s1len=<optimized out>) at ./debug/strlcpy_chk.c:28
#9 0x000055555557ac8a in strlcpy (__n=356, __src=0x89ab3c42edf52f00 <error: Cannot access memory at address 0x89ab3c42edf52f00>, __dest=0x7ffffffd5370 "agarcia") at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:156
#10 el_submit_attachment (lbs=lbs@entry=0x5555566873d8, afilename=afilename@entry=0x7ffffffd57e0 "pfSense-UDP4-1194-yuhaosun-config.ovpn",
buffer=buffer@entry=0x5555566bba67 "dev tun\npersist-tun\npersist-key\ndata-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC\ndata-ciphers-fallback AES-256-CBC\nauth SHA256\ntls-client\nclient\nresolv-retry infinite\nremote pfsense."...,
buffer_size=buffer_size@entry=5265, full_name=full_name@entry=0x7ffffffd58e0 "") at src/elogd.cxx:4547
#11 0x00005555555f91ea in decode_post (logbook=logbook@entry=0x7fffffffbff0 "He6", lbs=lbs@entry=0x5555566873d8, string=<optimized out>,
string@entry=0x5555566bb1c9 '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form-data; name=\"unm\"\r\n\r\ngholman\r\n", '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form"...,
boundary=boundary@entry=0x7fffffffbef0 '-' <repeats 27 times>, "16417726823211458101306576170", length=length@entry=7649) at src/elogd.cxx:28662
#12 0x00005555555fb5cc in process_http_request (
crequest=crequest@entry=0x555556656658 "POST /He6/ HTTP/1.0\r\nHost: xxx.xxx.xxx.xxx\r\nX-Real-IP: 192.168.101.2\r\nX-Forwarded-For: 192.168.101.2\r\nConnection: close\r\nContent-Length: 7649\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win6"...,
i_conn=i_conn@entry=0) at src/elogd.cxx:29317
#13 0x00005555555ffc68 in server_loop () at src/elogd.cxx:30302
#14 0x000055555555b1b9 in main (argc=<optimized out>, argv=<optimized out>) at src/elogd.cxx:31327
(gdb)
| Stefan Ritt wrote: |
|
A statement like "core dumped" does not help much. Same with valgrind memory leaks. I need a full strack trace with all parameters when the segment violation occurs. The easiest is when you run elogd vom inside gdb, and once you get the signal, do a "where" to see th full stack trace.
As you can see from this forum, there is absolutely no crash when you upload any file, so it must have to do with your config file or anything whcih is special in yoru environment. We have to find what this is so that I can reproduce it here.
Stefan
|
|
Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan |