| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69856
|
Thu Dec 12 20:29:40 2024 |
 | gary holman | holman@uw.edu | Bug report | Linux | elog-3.1.5-1 | Re: Segfault on elog-3.1.5-1 when uploading file. | 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
|
|
|
69855
|
Thu Dec 12 19:46:02 2024 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | elog-3.1.5-1 | Re: Segfault on elog-3.1.5-1 when uploading file. | 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 |
|
69854
|
Thu Dec 12 19:01:39 2024 |
| gary holman | holman@uw.edu | Bug report | Linux | elog-3.1.5-1 | Re: Segfault on elog-3.1.5-1 when uploading file. | 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
|
|
|
Draft
|
Thu Dec 12 19:01:39 2024 |
| gary holman | holman@uw.edu | Bug report | Linux | elog-3.1.5-1 | Re: Segfault on elog-3.1.5-1 when uploading file. | 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
|
|
|
69852
|
Thu Dec 12 18:45:49 2024 |
 | gary holman | holman@uw.edu | Bug report | Linux | elog-3.1.5-1 | Segfault on elog-3.1.5-1 when uploading file. | 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 |
| Attachment 1: elog-3.1.5-1-segfault-valgrind.txt
|
root@maxwell:~/elog-3.1.5-1# 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
==10756== Memcheck, a memory error detector
==10756== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==10756== Using Valgrind-3.22.0-bd4db67b1d-20231031 and LibVEX; rerun with -h for copyright info
==10756== Command: ./elogd -s /usr/local/elog -c /var/www/elog/he6/elogd.cfg -f /var/run/elog/he6.pid
==10756==
--10756-- Valgrind options:
--10756-- -v
--10756-- --leak-check=full
--10756-- --track-origins=yes
--10756-- Contents of /proc/version:
--10756-- Linux version 6.8.0-49-generic (buildd@lcy02-amd64-028) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #49-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 4 02:06:24 UTC 2024
--10756--
--10756-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-ssse3-avx-f16c-rdrand
--10756-- Page sizes: currently 4096, max supported 4096
--10756-- Valgrind library directory: /usr/libexec/valgrind
--10756-- Reading syms from /root/elog-3.1.5-1/elogd
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
--10756-- Considering /usr/lib/debug/.build-id/35/3e1b6cb0eebc08cf3ff812eae8a51b4efd684e.debug ..
--10756-- .. build-id is valid
--10756-- Reading syms from /usr/libexec/valgrind/memcheck-amd64-linux
--10756-- object doesn't have a dynamic symbol table
--10756-- Scheduler: using generic scheduler lock implementation.
--10756-- Reading suppressions file: /usr/libexec/valgrind/default.supp
==10756== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-10756-by-root-on-???
==10756== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-10756-by-root-on-???
==10756== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-10756-by-root-on-???
==10756==
==10756== TO CONTROL THIS PROCESS USING vgdb (which you probably
==10756== don't want to do, unless you know exactly what you're doing,
==10756== or are doing some strange experiment):
==10756== /usr/bin/vgdb --pid=10756 ...command...
==10756==
==10756== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==10756== /path/to/gdb ./elogd
==10756== and then give GDB the following command
==10756== target remote | /usr/bin/vgdb --pid=10756
==10756== --pid is optional if only one valgrind process is running
==10756==
--10756-- REDIR: 0x4028b00 (ld-linux-x86-64.so.2:strlen) redirected to 0x580c2e1a (???)
--10756-- REDIR: 0x40272b0 (ld-linux-x86-64.so.2:index) redirected to 0x580c2e34 (???)
--10756-- Reading syms from /usr/libexec/valgrind/vgpreload_core-amd64-linux.so
--10756-- Reading syms from /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so
==10756== WARNING: new redirection conflicts with existing -- ignoring it
--10756-- old: 0x04028b00 (strlen ) R-> (0000.0) 0x580c2e1a ???
--10756-- new: 0x04028b00 (strlen ) R-> (2007.0) 0x0484f340 strlen
--10756-- REDIR: 0x40274e0 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4850460 (strcmp)
--10756-- REDIR: 0x4026910 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4853cd0 (mempcpy)
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libssl.so.3
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libldap.so.2.0.200
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/liblber.so.2.0.200
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.33
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libc.so.6
--10756-- Considering /usr/lib/debug/.build-id/6d/64b17fbac799e68da7ebd9985ddf9b5cb375e6.debug ..
--10756-- .. build-id is valid
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libcrypto.so.3
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libcom_err.so.2.1
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libresolv.so.2
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libgnutls.so.30.37.1
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libm.so.6
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.1
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libidn2.so.0.4.0
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libunistring.so.5.0.0
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.3
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libnettle.so.8.8
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libhogweed.so.6.8
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libffi.so.8.1.4
--10756-- REDIR: 0x4028ca0 (ld-linux-x86-64.so.2:strncmp) redirected to 0x484fc90 (strncmp)
--10756-- REDIR: 0x4da5040 (libc.so.6:strnlen) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da50d0 (libc.so.6:strpbrk) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da3190 (libc.so.6:strcmp) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dbc3b0 (libc.so.6:wcsnlen) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da2280 (libc.so.6:memset) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dbbb20 (libc.so.6:wcslen) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4e273c0 (libc.so.6:__memcpy_chk) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da21f0 (libc.so.6:memrchr) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dbc350 (libc.so.6:wcsncpy) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da1710 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dba8e0 (libc.so.6:wcschr) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da3080 (libc.so.6:index) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da5100 (libc.so.6:rindex) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dba990 (libc.so.6:wcscmp) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da24a0 (libc.so.6:stpncpy) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dc8eb0 (libc.so.6:wmemchr) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4ee0 (libc.so.6:strncmp) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da2500 (libc.so.6:strcasecmp) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4300 (libc.so.6:strcspn) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dbb8f0 (libc.so.6:wcscpy) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da3010 (libc.so.6:strcat) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4de0 (libc.so.6:strncasecmp_l) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da3100 (libc.so.6:strchrnul) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da1620 (libc.so.6:bcmp) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4290 (libc.so.6:strcpy) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da25a0 (libc.so.6:strcasecmp_l) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4cb0 (libc.so.6:strlen) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4f80 (libc.so.6:strncpy) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4dc8f30 (libc.so.6:wmemcmp) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4e274e0 (libc.so.6:__memmove_chk) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
==10756== WARNING: new redirection conflicts with existing -- ignoring it
--10756-- old: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2030.0) 0x04853dd0 __memcpy_chk
--10756-- new: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2024.0) 0x04853740 __memmove_chk
--10756-- REDIR: 0x4da2430 (libc.so.6:stpcpy) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da1fb0 (libc.so.6:memmove) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da15a0 (libc.so.6:memchr) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da52d0 (libc.so.6:strspn) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da20d0 (libc.so.6:mempcpy) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4d40 (libc.so.6:strncasecmp) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
--10756-- REDIR: 0x4da4e80 (libc.so.6:strncat) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
==10756== WARNING: new redirection conflicts with existing -- ignoring it
--10756-- old: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2030.0) 0x04853dd0 __memcpy_chk
--10756-- new: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2024.0) 0x04853740 __memmove_chk
--10756-- REDIR: 0x4da5b90 (libc.so.6:strstr) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
==10756== WARNING: new redirection conflicts with existing -- ignoring it
--10756-- old: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2030.0) 0x04853dd0 __memcpy_chk
--10756-- new: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2024.0) 0x04853740 __memmove_chk
--10756-- REDIR: 0x4da2370 (libc.so.6:rawmemchr) redirected to 0x483d1c0 (_vgnU_ifunc_wrapper)
==10756== WARNING: new redirection conflicts with existing -- ignoring it
--10756-- old: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2030.0) 0x04853dd0 __memcpy_chk
--10756-- new: 0x04daa860 (__memcpy_chk_sse2_un) R-> (2024.0) 0x04853740 __memmove_chk
--10756-- REDIR: 0x4db7800 (libc.so.6:__strrchr_sse2) redirected to 0x484ed80 (__strrchr_sse2)
--10756-- REDIR: 0x4db1910 (libc.so.6:__strlen_sse2) redirected to 0x484f280 (__strlen_sse2)
--10756-- REDIR: 0x4daa2c0 (libc.so.6:__memcmp_sse2) redirected to 0x4852360 (__memcmp_sse2)
--10756-- REDIR: 0x4e99b30 (libc.so.6:__strncmp_sse42) redirected to 0x484fbd0 (__strncmp_sse42)
--10756-- REDIR: 0x4daf6b0 (libc.so.6:__strchr_sse2) redirected to 0x484eea0 (__strchr_sse2)
--10756-- REDIR: 0x4e971c0 (libc.so.6:__strcmp_sse42) redirected to 0x4850420 (__strcmp_sse42)
--10756-- REDIR: 0x4d9d640 (libc.so.6:malloc) redirected to 0x48467b0 (malloc)
--10756-- REDIR: 0x4daa860 (libc.so.6:__memcpy_chk_sse2_unaligned) redirected to 0x4853dd0 (__memcpy_chk)
--10756-- REDIR: 0x4d9e790 (libc.so.6:calloc) redirected to 0x484d8a0 (calloc)
--10756-- REDIR: 0x4daa870 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4850590 (memcpy@GLIBC_2.2.5)
--10756-- REDIR: 0x4d9dd20 (libc.so.6:free) redirected to 0x4849820 (free)
--10756-- REDIR: 0x4da9f80 (libc.so.6:__memchr_sse2) redirected to 0x48504e0 (memchr)
--10756-- REDIR: 0x4db65d0 (libc.so.6:__strncpy_sse2_unaligned) redirected to 0x484f940 (__strncpy_sse2_unaligned)
--10756-- REDIR: 0x4d9e090 (libc.so.6:realloc) redirected to 0x484db00 (realloc)
--10756-- REDIR: 0x4e95970 (libc.so.6:__strcasecmp_sse42) redirected to 0x484fcf0 (strcasecmp)
--10756-- REDIR: 0x4daa850 (libc.so.6:__mempcpy_sse2_unaligned) redirected to 0x48538d0 (mempcpy)
--10756-- REDIR: 0x4e95980 (libc.so.6:__strcasecmp_l_sse42) redirected to 0x484ff70 (strcasecmp_l)
--10756-- REDIR: 0x4dab5c0 (libc.so.6:__stpcpy_sse2_unaligned) redirected to 0x48527e0 (__stpcpy_sse2_unaligned)
--10756-- REDIR: 0x4db12e0 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x484f370 (strcpy)
--10756-- REDIR: 0x4daf8e0 (libc.so.6:__strchrnul_sse2) redirected to 0x48537b0 (strchrnul)
elogd 3.1.5 built Dec 12 2024, 09:17:06 --10756-- REDIR: 0x4e27f90 (libc.so.6:__strcpy_chk) redirected to 0x4853830 (__strcpy_chk)
revision fc6679b
File "/var/run/elog/he6.pid" exists, overwriting it.
==10756== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==10756== at 0x4D3540A: __libc_sigaction (libc_sigaction.c:58)
==10756== by 0x1B2726: server_loop() (elogd.cxx:29826)
==10756== by 0x10F1B8: main (elogd.cxx:31327)
==10756== Address 0x1ffefff0a8 is on thread 1's stack
==10756== in frame #0, created by __libc_sigaction (libc_sigaction.c:43)
==10756== Uninitialised value was created by a stack allocation
==10756== at 0x1B22F3: server_loop() (elogd.cxx:29646)
==10756==
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libnss_systemd.so.2
--10756-- Reading syms from /usr/lib/x86_64-linux-gnu/libcap.so.2.66
--10756-- REDIR: 0x4e9ac10 (libc.so.6:__strspn_sse42) redirected to 0x4854110 (strspn)
--10756-- REDIR: 0x4e9ab10 (libc.so.6:__strpbrk_sse42) redirected to 0x4853fc0 (strpbrk)
--10756-- REDIR: 0x4d9ee60 (libc.so.6:malloc_usable_size) redirected to 0x484e7a0 (malloc_usable_size)
--10756-- REDIR: 0x4db75e0 (libc.so.6:__strnlen_sse2) redirected to 0x484f1c0 (strnlen)
--10756-- REDIR: 0x4dab140 (libc.so.6:__memset_sse2_unaligned) redirected to 0x4852c50 (memset)
CKeditor detected
==10757==
==10757== HEAP SUMMARY:
==10757== in use at exit: 308,226 bytes in 996 blocks
==10757== total heap usage: 2,082 allocs, 1,086 frees, 862,536 bytes allocated
==10757==
==10757== Searching for pointers to 996 not-freed blocks
==10757== Checked 17,189,864 bytes
==10757==
==10757== 144 bytes in 6 blocks are possibly lost in loss record 30 of 45
==10757== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x119AE3: xmalloc (elogd.cxx:420)
==10757== by 0x119AE3: parse_config_file(char*) (elogd.cxx:2862)
==10757== by 0x11A64E: check_config_file(int) (elogd.cxx:2661)
==10757== by 0x10F06E: check_config (elogd.cxx:3370)
==10757== by 0x10F06E: main (elogd.cxx:31124)
==10757==
==10757== 156 bytes in 1 blocks are possibly lost in loss record 31 of 45
==10757== at 0x484DB80: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x113FDE: xrealloc(void*, unsigned long) (elogd.cxx:467)
==10757== by 0x119A94: parse_config_file(char*) (elogd.cxx:2861)
==10757== by 0x11A64E: check_config_file(int) (elogd.cxx:2661)
==10757== by 0x10F06E: check_config (elogd.cxx:3370)
==10757== by 0x10F06E: main (elogd.cxx:31124)
==10757==
==10757== 2,280 bytes in 6 blocks are possibly lost in loss record 38 of 45
==10757== at 0x484DB80: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x113FDE: xrealloc(void*, unsigned long) (elogd.cxx:467)
==10757== by 0x11A440: parse_config_file(char*) (elogd.cxx:2885)
==10757== by 0x11A64E: check_config_file(int) (elogd.cxx:2661)
==10757== by 0x10F06E: check_config (elogd.cxx:3370)
==10757== by 0x10F06E: main (elogd.cxx:31124)
==10757==
==10757== 2,492 bytes in 92 blocks are possibly lost in loss record 39 of 45
==10757== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x119F16: xmalloc (elogd.cxx:420)
==10757== by 0x119F16: parse_config_file(char*) (elogd.cxx:2888)
==10757== by 0x11A64E: check_config_file(int) (elogd.cxx:2661)
==10757== by 0x10F06E: check_config (elogd.cxx:3370)
==10757== by 0x10F06E: main (elogd.cxx:31124)
==10757==
==10757== 2,492 bytes in 92 blocks are possibly lost in loss record 40 of 45
==10757== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x119F65: xmalloc (elogd.cxx:420)
==10757== by 0x119F65: parse_config_file(char*) (elogd.cxx:2889)
==10757== by 0x11A64E: check_config_file(int) (elogd.cxx:2661)
==10757== by 0x10F06E: check_config (elogd.cxx:3370)
==10757== by 0x10F06E: main (elogd.cxx:31124)
==10757==
==10757== 3,504 bytes in 92 blocks are possibly lost in loss record 41 of 45
==10757== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x11A3AE: xmalloc (elogd.cxx:420)
==10757== by 0x11A3AE: parse_config_file(char*) (elogd.cxx:2906)
==10757== by 0x11A64E: check_config_file(int) (elogd.cxx:2661)
==10757== by 0x10F06E: check_config (elogd.cxx:3370)
==10757== by 0x10F06E: main (elogd.cxx:31124)
==10757==
==10757== 100,012 bytes in 1 blocks are possibly lost in loss record 44 of 45
==10757== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x1B234A: xmalloc (elogd.cxx:420)
==10757== by 0x1B234A: server_loop() (elogd.cxx:29673)
==10757== by 0x10F1B8: main (elogd.cxx:31327)
==10757==
==10757== 100,012 bytes in 1 blocks are definitely lost in loss record 45 of 45
==10757== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==10757== by 0x1B2311: xmalloc (elogd.cxx:420)
==10757== by 0x1B2311: server_loop() (elogd.cxx:29671)
==10757== by 0x10F1B8: main (elogd.cxx:31327)
==10757==
==10757== LEAK SUMMARY:
==10757== definitely lost: 100,012 bytes in 1 blocks
==10757== indirectly lost: 0 bytes in 0 blocks
==10757== possibly lost: 111,080 bytes in 290 blocks
==10757== still reachable: 97,134 bytes in 705 blocks
==10757== suppressed: 0 bytes in 0 blocks
==10757== Reachable blocks (those to which a pointer was found) are not shown.
==10757== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10757==
==10757== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0)
==10757==
==10757== 1 errors in context 1 of 9:
==10757== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==10757== at 0x4D3540A: __libc_sigaction (libc_sigaction.c:58)
==10757== by 0x1B2726: server_loop() (elogd.cxx:29826)
==10757== by 0x10F1B8: main (elogd.cxx:31327)
==10757== Address 0x1ffefff0a8 is on thread 1's stack
==10757== in frame #0, created by __libc_sigaction (libc_sigaction.c:43)
==10757== Uninitialised value was created by a stack allocation
==10757== at 0x1B22F3: server_loop() (elogd.cxx:29646)
==10757==
==10757== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0)
--10756-- REDIR: 0x4db7e10 (libc.so.6:__strstr_sse2_unaligned) redirected to 0x4853e40 (strstr)
ImageMagick detected
Indexing logbooks ... done
Server listening on port 8088 ...
==10756== Conditional jump or move depends on uninitialised value(s)
==10756== at 0x1A8AA1: interprete(char*, char const*) (elogd.cxx:27599)
==10756== by 0x1AC2EC: decode_get(char*, char*) (elogd.cxx:28411)
==10756== by 0x1AFAF8: process_http_request(char const*, int) (elogd.cxx:29287)
==10756== by 0x1B3C67: server_loop() (elogd.cxx:30302)
==10756== by 0x10F1B8: main (elogd.cxx:31327)
==10756== Uninitialised value was created by a stack allocation
==10756== at 0x1A7E0A: interprete(char*, char const*) (elogd.cxx:27161)
==10756==
--10756-- REDIR: 0x4e27eb0 (libc.so.6:__stpcpy_chk) redirected to 0x4853880 (__stpcpy_chk)
--10756-- REDIR: 0x4e97f70 (libc.so.6:__strcspn_sse42) redirected to 0x4854010 (strcspn)
==10756== Syscall param write(buf) points to uninitialised byte(s)
==10756== at 0x4E0C574: write (write.c:26)
==10756== by 0x15F559: is_file_system_full (elogd.cxx:25830)
==10756== by 0x15F559: set_user_password(LOGBOOK*, char*, char*) (elogd.cxx:26038)
==10756== by 0x1A9956: interprete(char*, char const*) (elogd.cxx:27503)
==10756== by 0x1AC73E: decode_post(char*, LOGBOOK*, char*, char const*, int) (elogd.cxx:28727)
==10756== by 0x1AF5CB: process_http_request(char const*, int) (elogd.cxx:29317)
==10756== by 0x1B3C67: server_loop() (elogd.cxx:30302)
==10756== by 0x10F1B8: main (elogd.cxx:31327)
==10756== Address 0x1ffefd5240 is on thread 1's stack
==10756== in frame #1, created by set_user_password(LOGBOOK*, char*, char*) (elogd.cxx:25987)
==10756== Uninitialised value was created by a stack allocation
==10756== at 0x15F3C7: set_user_password(LOGBOOK*, char*, char*) (elogd.cxx:25987)
==10756==
--10756-- REDIR: 0x4aff8e0 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x4846f30 (operator new(unsigned long))
--10756-- REDIR: 0x4afd8a0 (libstdc++.so.6:operator delete(void*)) redirected to 0x484a080 (operator delete(void*))
--10756-- REDIR: 0x4afd8b0 (libstdc++.so.6:operator delete(void*, unsigned long)) redirected to 0x484a530 (operator delete(void*, unsigned long))
==10756== Syscall param write(buf) points to uninitialised byte(s)
==10756== at 0x4E0C574: write (write.c:26)
==10756== by 0x15EF6A: is_file_system_full (elogd.cxx:25830)
==10756== by 0x15EF6A: set_user_login_time(LOGBOOK*, char*) (elogd.cxx:25913)
==10756== by 0x1614DC: check_login(LOGBOOK*, char const*) (elogd.cxx:26409)
==10756== by 0x1A8B37: interprete(char*, char const*) (elogd.cxx:27615)
==10756== by 0x1AC2EC: decode_get(char*, char*) (elogd.cxx:28411)
==10756== by 0x1AFAF8: process_http_request(char const*, int) (elogd.cxx:29287)
==10756== by 0x1B3C67: server_loop() (elogd.cxx:30302)
==10756== by 0x10F1B8: main (elogd.cxx:31327)
==10756== Address 0x1ffefd6450 is on thread 1's stack
==10756== in frame #1, created by set_user_login_time(LOGBOOK*, char*) (elogd.cxx:25838)
... 349 more lines ...
|
|
69851
|
Tue Dec 10 19:23:32 2024 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Linux | Other | Latest version | Re: no availability of el8 and el9 rpm | > People are keeping me asking for a Windows installer
My Windows-11 laptop may free up in January and I could look at builds of elog and midas, but I know nothing about making Windows installers...
K.O. |
|
69850
|
Tue Dec 10 15:34:41 2024 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Other | Latest version | Re: no availability of el8 and el9 rpm | People are keeping me asking for a Windows installer. Is this now properly working, also under Windows 11? If you send me the executable, I could upload it to the distribution.
Do people have to install cygwin before they can use it, or will the executable runn just by itself? If I understand correctly, the MinGW package would not require a runtime library, right?
Best,
Stefan
| Laurent Jean-Rigaud wrote: |
|
Hi Stefan,
Some updates for Windows version.
I spent last WE to try to build ELOG on Windows from MSVCODE, MSCV, crosschain tool under linux etc, but in vain.
ELOG MSVC projects file are obsolete for last MS C++, and after migration, so much error or missing libs for SSL/Ldap/krb5 which should be built... I drop the sponge :-P
With mingw64 under Linux (docker/Debian), the code has also to be updated (C++11), but I don't get a build after all (also libs missing and must be built).
Finally, I can build Windows version from Windows with CygWin gcc-c++ as I did in the past. All the dependencies are available from CygWin installer. I got problems with strlcpy file missing, need to drop inlcude from elog.c and elogd.h as mxml doesn't include it anymore...
I find a Win64 CI/CD solution on AppVeyor which is free for OSS project. After creating account and add link to my ELOG test Bitbucket repo, ad new files (appveyor.yml, buildming script, update NSIS script for CygWin DDL, add tool for service), it builds automatically an elog-ver-release.exe artifact : (current build from GIT with SSL/LDAP/KRB5 available on month up to March 3, 2024 : https://ci.appveyor.com/api/buildjobs/logp7r8f0kcjq9pp/artifacts/elog-3.1.5-a720145.exe)
I installed this NSIS bundle on my PC and it's starting fine as a service.
The link info from EXE :
$ ldd /cygdrive/c/Program\ Files\ \(x86\)/ELOG/elogd.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffdb1fb0000)
KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL (0x7ffdb0dc0000)
KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll (0x7ffdaf950000)
cygwin1.dll => /cygdrive/c/Program Files (x86)/ELOG/cygwin1.dll (0x7ffcedc30000)
cygkrb5-3.dll => /cygdrive/c/Program Files (x86)/ELOG/cygkrb5-3.dll (0x3fe0a0000)
cyglber-2.dll => /cygdrive/c/Program Files (x86)/ELOG/cyglber-2.dll (0x3fe040000)
cygldap-2.dll => /cygdrive/c/Program Files (x86)/ELOG/cygldap-2.dll (0x3fdf20000)
cygssl-3.dll => /cygdrive/c/Program Files (x86)/ELOG/cygssl-3.dll (0x3fd0d0000)
cyggcc_s-seh-1.dll => /cygdrive/c/Program Files (x86)/ELOG/cyggcc_s-seh-1.dll (0x3ff1d0000)
cygstdc++-6.dll => /cygdrive/c/Program Files (x86)/ELOG/cygstdc++-6.dll (0x3fcee0000)
cygk5crypto-3.dll => /cygdrive/c/Program Files (x86)/ELOG/cygk5crypto-3.dll (0x3fe170000)
cygkrb5support-0.dll => /cygdrive/c/Program Files (x86)/ELOG/cygkrb5support-0.dll (0x3fe080000)
cygcom_err-2.dll => /cygdrive/c/Program Files (x86)/ELOG/cygcom_err-2.dll (0x3ffe90000)
cygintl-8.dll => /cygdrive/c/Program Files (x86)/ELOG/cygintl-8.dll (0x3fe450000)
cygcrypto-1.1.dll => /cygdrive/c/Program Files (x86)/ELOG/cygcrypto-1.1.dll (0x3ffbc0000)
cygsasl2-3.dll => /cygdrive/c/Program Files (x86)/ELOG/cygsasl2-3.dll (0x3fd3e0000)
cygssl-1.1.dll => /cygdrive/c/Program Files (x86)/ELOG/cygssl-1.1.dll (0x3fd170000)
cygcrypto-3.dll => /cygdrive/c/Program Files (x86)/ELOG/cygcrypto-3.dll (0x3ff800000)
cygiconv-2.dll => /cygdrive/c/Program Files (x86)/ELOG/cygiconv-2.dll (0x3fe540000)
cygz.dll => /cygdrive/c/Program Files (x86)/ELOG/cygz.dll (0x3fc790000)
I will send you the files/patchs if AppVeyor could be used for Windows CI/CD in your project.
Bye,
Laurent
NB: the AppVeyor build log enclosed, need some cleanup...
| Stefan Ritt wrote: |
| Laurent Jean-Rigaud wrote: |
|
For Windows target, It's supported in Bitbucket but only with private agent :-(
So I tried to build using docker hub MSVC image (abrarov/msvc-2019) but pipeline fails to retrieve the image. Maybe I need to swipe on alternative images, or these images with MS software are unaccepted from Atlassian...
Also, I tried to crosscompiling ELOG Win32 from Linux with g++-mingw-w64-x86-64, but Makefile/sources need to be patched to manage this 'platform'... For the moment, it fails. :-(
Next solution : use Wine in Debian image to build Elog with mingwin as I know that it works (under Windows :-)). Will be tested after all...
|
For Windows it's more than just getting the .exe. Users want an installer. I used the Nullsoft Scriptable Installer (NSI), but I have no clue if this still works today. But there is still the elog.nsi script in the repository. Next, users want elogd as a service running in the background as a "service". I'm pretty sure the old way of doing that has changed and one would at least have to test this. Unfortunatley I switched to MacOSX about ten years ago (actually most of ELOG has been developed under Windows, but these days are gone), so I'm kind of illiterate in the Windows world now and don't have any time to change that.
Stefan
|
|
|
|
69849
|
Mon Dec 9 21:55:53 2024 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Linux | 3.1.5 | Re: Probleme TLS | What Stefan meant to say is that Elog does not implement sending email using encrypted SMTP over TLS.
In theory it could be implemented, but if you try to use it, you may find that most
destinations will reject you unless you have configured correct SPF records.
https://en.wikipedia.org/wiki/Sender_Policy_Framework
Even if you do everything right, joints like gmail may still reject you because
their AI decides you are a spammer, or just because they do not like you, and good
luck making them change their mind.
At TRIUMF, we configure elog to use unencrypted and unauthenticated SMTP
to smtp.triumf.ca, which has special rules to accept our email (no questions asked),
and our Microsoft email instance is configured to accept and forward email from
smpt.triumf.ca. Everything is done right, but we still see Fermilab's Microsoft
rejecting TRIUMF's Microsoft email once in a while.
K.O. |
|