Re: Segfault on elog-3.1.5-1 when uploading file., posted by gary holman on Thu Dec 12 19:01:39 2024
|
Looks like duplicate report to https://elog.psi.ch/elogs/Forum/69826
| gary holman wrote: |
|
I am receiving a segfault whenever I attempt to upload a file. Please see attached .txt for valgrind output. This occurs in version elog-3.1.5-1. I reverted back to version elog-3.1.4-3 and the segfault does not occur.
Segfault occurs in Elog version: elog-3.1.5-1
System:
Virtualization: kvm
Operating System: Ubuntu 24.04.1 LTS
Kernel: Linux 6.8.0-49-generic
Architecture: x86-64
Hardware Vendor: QEMU
Hardware Model: Standard PC _Q35 + ICH9, 2009_
Firmware Version: 1.15.0-1
Firmware Date: Tue 2014-04-01
Firmware Age: 10y 8month 1w 5d
Valgrind command: valgrind -v --leak-check=full --track-origins=yes ./elogd -s /usr/local/elog -c /var/www/elog/he6/elogd.cfg -f /var/run/elog/he6.pid
Steps to reproduce:
1. Login elog
2. Create new logbook entry
3. Attachement 1: Select Browse
4. Select any file.
5. Select Upload
|
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by gary holman on Thu Dec 12 20:29:40 2024
|
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
|
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by gary holman on Fri Dec 13 19:40:57 2024
|
Thanks Stefen!
I built from source (ELOG V3.1.5-3a5f2f00) and I confirmed as fixed.
| Stefan Ritt wrote: |
|
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
|
|
new entry form - "minimalist" approach , posted by frederic poncin on Mon Sep 18 16:53:09 2006
|
I'm playing with the configuration files in order to produce a "minimal" form.
At this time, I did not succeed in removing the following components:
- the "Fields marked with * are required" field
- the "Entry time:" field
- the "encoding ELCode / plain / HTML" field
- the "preview" button
- the duplication of the Submit/Preview/Back buttons on the top and the bottom of the page.
Is any of this possible?
--
Frédéric Poncin |
|
Locking entries, posted by filantoro on Wed Sep 1 03:42:22 2004
|
I have a question about ELOG. Let's say after the user finishes his shift
and passess on to the next user on duty. A staff member would want to look
through the entries and vet them. The staff could lock the entries to
maintain integrity of the information. How can that be done with ELOG? Can
you enlighten me. Thank u. |
Possible misuse of email headers Message-Id and In-Reply-To, posted by fbretel on Wed Feb 8 16:38:15 2017
|
Hi,
As mentionned before, we happen to fail to receive email messages related to updates on elog entries at our site. My understanding is that the SMTP header Message-Id MUST be unique for each email message. Whereas all elogd email messages get something like <logbook>-<entryId>@<domain>. See source code. For this header to become unique, there should be a random part in it.
Having the same Message-Id in multiple email messages results in only the first one being delivered on some email systems.
Moreover, elogd sets the In-Reply-To: header in the same manner (<logbook>-<entryId>@<domain>). Which is incorrect because this header relates to email messages, not elog entries, and should contain the email Message-Id of the email message to which it replies, itself handled by the email messaing system. But elogd hasn't received any email messsage in the first place. So I believe this header should simply be dropped.
I think I can provide a pull request on bitbucket for the Message-Id issue, and probably also for the In-Reply-To: if you decide it can be removed.
Cheers |
|
Re: Possible misuse of email headers Message-Id and In-Reply-To, posted by fbretel on Wed Mar 15 16:04:13 2017
|
Pull-request posted. Cheers. |
|
How can change the justification of a column?, posted by fabio vitale on Mon Jan 30 17:52:20 2017
|
It is possible to change the justification for a column/attribute in the list mode (left-aligned, centered, right-aligned)?
Right now Elog treats each colum of a list as centered,
thank you |
|