ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 761 of 806

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

6445 Entries

Goto page Previous 1, 2, 3 ... 760, 761, 762 ... 804, 805, 806 Next

ID	Date	Author	Author Email	Category	OS	ELOG Version	Subject
69693	Fri Sep 15 21:42:38 2023	Konstantin Olchanski	olchansk@triumf.ca	Bug report	Other	latest	update elog downloads page
The elog downloads page is slightly out of date, https://elog.psi.ch/elog/download.html 1) the "git clone" instructions work (but there is no git tags corresponding to different releases, I suggest adding test: "elog developers recommend always using latest version from elog git repository"). 2) "elog source code", recommends downloading tar file, but latest tar file is from February 2023, probably out of date. people who can compile elog from sources can do "git clone", is the "tar" method still relevant? 3) windows binaries, latest available is from 2018, before the famous security fixes, probably no longer safe for running on the open internet. I suggest we remove this section and say "sorry, windows binaries no longer available". 4) linux binaries, all links are dead, and we have requested removal of elog packages from red hat, debian and ubuntu. (and they have been removed). K.O.
69712	Mon Jan 8 11:06:49 2024	Dr Marta Divall	marta.divall@epfl.ch	Question	Windows	ELOG V3.1.3-a38	Maximum number of attributes
The maximum number or attributes is 100. Is it possible to increase this? Thanks!
69772	Mon Apr 8 10:49:10 2024	Stefano Lacaprara	stefano.lacaprara@pd.infn.it	Question	Linux	ELOG V3.1.4-395	today date in template
Hello, I am using template for some elogbook entries. Is is possible to automatically change the template using the actual date in some filed. Something like: the template has a place-holder <start date> and this is replaced with today's date when a new entry is created. I already have a "date" filed which is automatically filled, but I've been asked to have the date also in the template. Thanks in advance Stefano
69807	Mon Jul 22 16:17:55 2024	André	andre.althaus@tu-dortmund.de	Bug report	All	3.1.5	HTTP headers should be parsed case insensitive
I'm trying to run elog behind haproxy, but get the error "Invalid Content-Length in header" on posting. As stated in the manual, haproxy rewrites all headers to lower case. elogd parses the content-length header case sensitive which is against the HTTP RFC. This might also apply to other headers that get parsed. For now I'm using the workaround from the manual: `global h1-case-adjust content-length Content-Length h1-case-adjust content-type Content-Type` `backend elog option h1-case-adjust-bogus-server server elog 127.0.0.1:8080` But as the manual states, this should not be used as a permanent solution.
69811	Fri Jul 26 12:52:54 2024	Carl Unsworth	carl.unsworth@stfc.ac.uk	Bug report	Linux	V3.1.5-23df00d	Old attachments erroneously appearing on new Elog entries.
Hi, I'm not sure if this is an Elog bug, something wrong in my configuration/database. When I create a new article on Elog it always shows an attachment from one of the first entries ever made to this log book made. This is in addition to any attachments which were actually added during article creation. I just made an example entry to demonstrate. First attachment here shows how the entry looks in the GUI, it has an attached text file called "jail.local", 2nd attachment is how that entry looks in the database file - no attachment. Does anyone have any idea what's happening?
Attachment 1: Screenshot_from_2024-07-26_11-46-44.png

Attachment 2: Screenshot_from_2024-07-26_11-47-58.png

69831	Tue Sep 24 19:38:23 2024	Gabriel Lopez	gabelopez@bnl.gov	Bug report	Linux	elog-3.1.4-3	Catgegory filtering
Currently have multiple logbooks hosted with elogd. One book is having an issue with Categories. The user regulary uses the category filtering to see one subject for the whole month. This past week it hasn't been working properly. When choosing a drop down category to filter there are not logs found. I've notice the fields under the categories change randomly. Sometimes it would add a % sign where there should be --. Some other fields go from displaying -- Subject -- to just the dashes, thats when the filtered eLogs do not show. Clearing out the erroneous characters can eventually load the specified logs. Has anyone else seen this? Should I just upgrade the system and hope for the best? PS. while writing this I was able to mitigate the issue by removing the troubled fields from the quick filter section. I'm pretty sure this will not be an issue for my end user but any input is appreciated.
69842	Mon Dec 2 10:36:41 2024	Dr Marta Divall	marta.divall@epfl.ch	Question	Linux \| Windows	ELOG V3.1.3-a38	Global change of links/file path
Dear All, We have been using the ELOG for several years and had inserted hyper-links instead of whole files in order to save storage space. From this month our server is moved to a new location with a new address. Is there a way for me to retrospectivelly replace all addresses with the new server file pass? Thanks in advance, Best regards, Marta
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 ...

Goto page Previous 1, 2, 3 ... 760, 761, 762 ... 804, 805, 806 Next

ELOG V3.1.5-3fb85fa6