indeed, I'll try to move to ELOG V3.1.4-80633ba

> My try on this server ->> see the subject

> indeed, I'll try to move to ELOG V3.1.4-80633ba
> 
> > My try on this server ->> see the subject

I've tried with elog-3.1.4-2 and git version, and I still have the same problem. 
If I compile with make debug, it works.

Is there anything I can do to help debug the problem?

thanks for your help

S

compiling git master w/o debug, but running in gdb


gdb ~/elog/elogd
(gdb) run -f /var/run/elog.pid -c /etc/elog.conf -d /var/lib/elog/logbooks -s /usr/share/elog -v 3 -x
... [opening elogbook demo with an entry with lorem ipsum as sujbject] 

*** buffer overflow detected ***: /root/elog/elogd terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ffff781b7e5]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7ffff78bd15c]
/lib/x86_64-linux-gnu/libc.so.6(+0x117160)[0x7ffff78bb160]
/lib/x86_64-linux-gnu/libc.so.6(+0x1166c9)[0x7ffff78ba6c9]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x80)[0x7ffff781f6b0]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x139b)[0x7ffff77f250b]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7ffff78ba754]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7ffff78ba6ad]
/root/elog/elogd[0x44c86a]
/root/elog/elogd[0x4799e0]
/root/elog/elogd[0x496018]
/root/elog/elogd[0x4962a6]
/root/elog/elogd[0x49864e]
/root/elog/elogd[0x49b1f8]
/root/elog/elogd[0x4038c7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff77c4830]
/root/elog/elogd[0x404509]
======= Memory map: ========
00400000-004d5000 r-xp 00000000 ca:01 273573                             /root/elog/elogd
006d4000-006d5000 r--p 000d4000 ca:01 273573                             /root/elog/elogd
006d5000-0076c000 rw-p 000d5000 ca:01 273573                             /root/elog/elogd
0076c000-018e7000 rw-p 00000000 00:00 0                                  [heap]
7ffff5783000-7ffff5799000 r-xp 00000000 ca:01 651589                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff5799000-7ffff5998000 ---p 00016000 ca:01 651589                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff5998000-7ffff5999000 rw-p 00015000 ca:01 651589                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff5999000-7ffff5c56000 rw-p 00000000 00:00 0 
7ffff5cda000-7ffff66c7000 r--s 00000000 ca:03 1305745                    /var/lib/sss/mc/initgroups
7ffff66c7000-7ffff66df000 r-xp 00000000 ca:01 652670                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7ffff66df000-7ffff68de000 ---p 00018000 ca:01 652670                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7ffff68de000-7ffff68df000 r--p 00017000 ca:01 652670                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7ffff68df000-7ffff68e0000 rw-p 00018000 ca:01 652670                     /lib/x86_64-linux-gnu/libpthread-2.23.so
7ffff68e0000-7ffff68e4000 rw-p 00000000 00:00 0 
7ffff68e4000-7ffff68ec000 r-xp 00000000 ca:01 651532                     /lib/x86_64-linux-gnu/libnss_sss.so.2
7ffff68ec000-7ffff6aeb000 ---p 00008000 ca:01 651532                     /lib/x86_64-linux-gnu/libnss_sss.so.2
7ffff6aeb000-7ffff6aec000 r--p 00007000 ca:01 651532                     /lib/x86_64-linux-gnu/libnss_sss.so.2
7ffff6aec000-7ffff6aed000 rw-p 00008000 ca:01 651532                     /lib/x86_64-linux-gnu/libnss_sss.so.2
7ffff6aed000-7ffff6af8000 r-xp 00000000 ca:01 652680                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7ffff6af8000-7ffff6cf7000 ---p 0000b000 ca:01 652680                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7ffff6cf7000-7ffff6cf8000 r--p 0000a000 ca:01 652680                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7ffff6cf8000-7ffff6cf9000 rw-p 0000b000 ca:01 652680                     /lib/x86_64-linux-gnu/libnss_files-2.23.so
7ffff6cf9000-7ffff6cff000 rw-p 00000000 00:00 0 
7ffff6cff000-7ffff715b000 r--p 00000000 ca:01 134295                     /usr/lib/locale/locale-archive
7ffff715b000-7ffff715e000 r-xp 00000000 ca:01 652668                     /lib/x86_64-linux-gnu/libdl-2.23.so
7ffff715e000-7ffff735d000 ---p 00003000 ca:01 652668                     /lib/x86_64-linux-gnu/libdl-2.23.so
7ffff735d000-7ffff735e000 r--p 00002000 ca:01 652668                     /lib/x86_64-linux-gnu/libdl-2.23.so
7ffff735e000-7ffff735f000 rw-p 00003000 ca:01 652668                     /lib/x86_64-linux-gnu/libdl-2.23.so
7ffff735f000-7ffff757a000 r-xp 00000000 ca:01 651557                     /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7ffff757a000-7ffff7779000 ---p 0021b000 ca:01 651557                     /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7ffff7779000-7ffff7795000 r--p 0021a000 ca:01 651557                     /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7ffff7795000-7ffff77a1000 rw-p 00236000 ca:01 651557                     /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7ffff77a1000-7ffff77a4000 rw-p 00000000 00:00 0 
7ffff77a4000-7ffff7964000 r-xp 00000000 ca:01 652683                     /lib/x86_64-linux-gnu/libc-2.23.so
7ffff7964000-7ffff7b64000 ---p 001c0000 ca:01 652683                     /lib/x86_64-linux-gnu/libc-2.23.so
7ffff7b64000-7ffff7b68000 r--p 001c0000 ca:01 652683                     /lib/x86_64-linux-gnu/libc-2.23.so
7ffff7b68000-7ffff7b6a000 rw-p 001c4000 ca:01 652683                     /lib/x86_64-linux-gnu/libc-2.23.so
7ffff7b6a000-7ffff7b6e000 rw-p 00000000 00:00 0 
7ffff7b6e000-7ffff7bcc000 r-xp 00000000 ca:01 651645                     /lib/x86_64-linux-gnu/libssl.so.1.0.0
7ffff7bcc000-7ffff7dcc000 ---p 0005e000 ca:01 651645                     /lib/x86_64-linux-gnu/libssl.so.1.0.0
7ffff7dcc000-7ffff7dd0000 r--p 0005e000 ca:01 651645                     /lib/x86_64-linux-gnu/libssl.so.1.0.0
7ffff7dd0000-7ffff7dd7000 rw-p 00062000 ca:01 651645                     /lib/x86_64-linux-gnu/libssl.so.1.0.0
7ffff7dd7000-7ffff7dfd000 r-xp 00000000 ca:01 652669                     /lib/x86_64-linux-gnu/ld-2.23.so
7ffff7fd9000-7ffff7fde000 rw-p 00000000 00:00 0 
7ffff7ff7000-7ffff7ff8000 rw-p 00000000 00:00 0 
7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0                          [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0                          [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00025000 ca:01 652669                     /lib/x86_64-linux-gnu/ld-2.23.so
7ffff7ffd000-7ffff7ffe000 rw-p 00026000 ca:01 652669                     /lib/x86_64-linux-gnu/ld-2.23.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 
7fffffe68000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Program received signal SIGABRT, Aborted.
0x00007ffff77d9428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) where
#0  0x00007ffff77d9428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff77db02a in __GI_abort () at abort.c:89
#2  0x00007ffff781b7ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff793349f "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff78bd15c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7ffff7933430 "buffer overflow detected") at fortify_fail.c:37
#4  0x00007ffff78bb160 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff78ba6c9 in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at vsprintf_chk.c:31
#6  0x00007ffff781f6b0 in __GI__IO_default_xsputn (f=0x7ffffff36d90, data=<optimized out>, n=1499) at genops.c:455
#7  0x00007ffff77f250b in _IO_vfprintf_internal (s=s@entry=0x7ffffff36d90, format=<optimized out>, format@entry=0x4b66bf "Style %s %s", 
ap=ap@entry=0x7ffffff36ec8) at vfprintf.c:1632
#8  0x00007ffff78ba754 in ___vsprintf_chk (
    s=0x7ffffff376a0 "Style Subject Lorem ipsum dolor sit amet, ut solum conceptam dissentiet per, affert argumentum te pro. Dicta tractatos 
intellegebat an ius. Mei munere soleat voluptatum cu, at vidit scriptorem consect"..., flags=1, slen=1500, format=0x4b66bf "Style %s %s", 
args=args@entry=0x7ffffff36ec8) at vsprintf_chk.c:82
#9  0x00007ffff78ba6ad in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:31
#10 0x000000000044c86a in display_line ()
#11 0x00000000004799e0 in show_elog_list ()
#12 0x0000000000496018 in interprete ()
#13 0x00000000004962a6 in decode_get ()
#14 0x000000000049864e in process_http_request ()
#15 0x000000000049b1f8 in server_loop ()
#16 0x00000000004038c7 in main ()

> I found two potential memory leaks which I fixed in the git version, so you can try again.

Just tested, and it works! Many thanks for very quick patch!

> 
> Another possibility, which is actually preferred, is to limit the size of the subject filed to a reasonable number. You can do that with following 
option
> 
> Format subject = 0, attribname, attribvalue, 80, 200

Yes, that is a good suggestion, I'll implemented it.

Many thanks again!

Best,
  Stefano

> 
> This shows the subject line with a width of 80 characters, but does only allow 200 characters to be entered there.
> 
> Best,
> Stefan

Dear expert,
  I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect 
as far as I can see.

Has anyone experienced something similar or has any idea how can I start to debug the problem?

Sorry for lack of many information, but I don't know what to look at.

Thanks in advance
  Stefano

Dear experts,
   I have a logbook which has authentication as follow

Authentication = LDAP, File
Password file = PASSWD.file
LDAP server = ldaps://it-ldap-XXX.XXX.XX:1636
LDAP userbase = ou=people,ou=RGY,o=XXX,c=XX
LDAP login attribute = uid
LDAP register = 0
Self register = 0
Allow password change = 0

Some of the my user (but not all) have issue in accessing this protected elogbook.
The ldap password is correct (we checked).
What I see in the log is as follow:

22-Feb-2021 11:25:51 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)
22-Feb-2021 11:25:59 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)

The user USERNAME is present in PASSWD.file.

For other user, for which the login works, I do see an (attempt) and then (success)

we tried the standard stuff: clear cache/cookies and with different browser. We also tried to remove the user from PASSWD.file and 
create it again, but nothing has worked.

Any suggestion how I can debug this problem?

Thanks in advance,
  Stefano

Hi,
  I'm running 
elogd 3.1.4 built Jan 27 2021, 09:56:34 revision 395e101a
on an ubuntu server.

I have a crash when very long filename (200 chars) are attached to an logbook entry.

The uploading of the attachment works almost fine: the filename is truncated and the convert to thumbnail is not working (as a consequence, maybe) but the file is actually uploaded and can be 
downloaded correctly from the entry itself.

However, if I try to access the logbook list which contains that entry, I have a crash:

*** buffer overflow detected ***: terminated
Aborted (core dumped)

[backtrace is attached below]

The only way I found to solve this is to edit manually the log entry and delete the attachment from it.

Any suggestion how to solve this?

Thanks
  Stefano


*** buffer overflow detected ***: terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bp
Undefined command: "bp".  Try "help".
(gdb) backtrace 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
#2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
#4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
#6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
#7  __GI__IO_default_xsputn (f=0x7ffffff36ca0, data=<optimized out>, n=241) at genops.c:370
#8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36ca0, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36de0, mode_flags=mode_flags@entry=6)
    at ../libio/libioP.h:948
#9  0x00007ffff7d57129 in __vsprintf_internal (
    string=0x7ffffff37120 
"../DAQ/220325_090630/j5K1OSy8XN9FRPriaBGOmMg3bih07CQKo68Sw6dskclxdOqKaTOsf2bX8UugSWn0s8zaAHe6VWiPcQVnmD8PM1tbQoVMr08dBrXKU2X2tBR4pJ3hlfxbKjspmcbiDTMy32eHIp6lFAVA9lppShmpiut4g4CtgDK3F2bOPzgzXEjPw
W0SJWG"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", args=args@entry=0x7ffffff36de0, mode_flags=6) at iovsprintf.c:95
#10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
#11 0x00005555555a939d in display_line ()
#12 0x00005555555ddc8a in show_elog_list ()
#13 0x00005555556010cf in interprete ()
#14 0x0000555555601a33 in decode_get ()
#15 0x000055555560461f in process_http_request ()
#16 0x0000555555607745 in server_loop ()
#17 0x000055555555a92c in main ()

Hi Stefan,
  

> Hi Stefano,
> 
> well, why in heaven's name do you run 200+ chars file names?

This is a very good question, and I asked the same to my user: the use case is typically that the attachment names are generated programmatcally, and many steps of the script add a string to it, plus sometime the original filename has hiragana or even kanji character.

So, long story short, it has happened in our production environment

The file I'm using was indeed generated from /dev/random, but that was the earies way fo rme to create such long filename.

Backtrace with lines is as follow.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
#2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
#4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
#6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
#7  __GI__IO_default_xsputn (f=0x7ffffff36c70, data=<optimized out>, n=241) at genops.c:370
#8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36c70, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36db0, mode_flags=mode_flags@entry=6) at ../libio/libioP.h:948
#9  0x00007ffff7d57129 in __vsprintf_internal (
    string=0x7ffffff370f0 "../DAQ/220329_090332/IjU4CK54jRBuQhOdUANqC6X8i8x1yoGGKozhtuM2M0Cc8MnauDwSzAs0BiVwAIzyC4TJqmDArrIA9Exja36xXqc6PSUjOE5hkiW1YeG1R9FM64tmdq52vvo1NsqLOk6I02RBlgnQB7hoUQa1fwb8ZdoRo3BJ9WJGq2sErewo8BL9dAZhZF9"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", 
args=args@entry=0x7ffffff36db0, mode_flags=6) at iovsprintf.c:95
#10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
#11 0x00005555555a939d in sprintf (__fmt=0x555555622e74 "../%s/%s/%s", __s=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:36
#12 display_line (lbs=0x55555664b818, message_id=9, number=<optimized out>, mode=0x7ffffffd2b80 "Summary", expand=1, level=0, printable=0, n_line=3, show_attachments=0, show_att_column=1, 
    date=0x7ffffffd2a40 "Tue, 29 Mar 2022 09:03:35 +0000", in_reply_to=0x7ffffffd2a90 "", reply_to=0x7ffffffd3160 "", n_attr_disp=7, disp_attr=0x7ffffff86760, disp_attr_link=0x7ffffff386a0, attrib=0x7ffffff3d380, 
    n_attr=5, text=0x5555567f26f8 "", show_text=1, attachment=0x7ffffff3a180, encoding=0x7ffffffd2ae0 "plain", select=0, n_display=0x7ffffff38438, locked_by=0x7ffffffd2d60 "", highlight=0, re_buf=0x7ffffff38840, 
    highlight_mid=0, absolute_link=0, draft=0x7ffffffd2f60 "") at src/elogd.c:18214
#13 0x00005555555ddc8a in show_elog_list (lbs=<optimized out>, past_n=<optimized out>, last_n=<optimized out>, page_n=<optimized out>, default_page=<optimized out>, info=<optimized out>) at src/elogd.c:21741
#14 0x00005555556010cf in interprete (lbook=<optimized out>, path=<optimized out>) at src/elogd.c:28362
#15 0x0000555555601a33 in decode_get (logbook=0x7fffffffbda0 "DAQ", string=<optimized out>) at src/elogd.c:28401
#16 0x000055555560461f in process_http_request (request=<optimized out>, i_conn=<optimized out>) at src/elogd.c:29209
#17 0x0000555555607745 in server_loop () at src/elogd.c:30233
#18 0x000055555555a92c in main (argc=<optimized out>, argv=<optimized out>) at src/elogd.c:31258


I'm not using the latest git version, but elog-3.1.4-3 from tar-ball, as I'm not able to compile elog from git
Is there any special thing I have to do?

In file included from src/auth.cxx:30:
src/elogd.h:282:40: note:   initializing argument 2 of ‘int get_user_line(LOGBOOK*, char*, char*, char*, char*, BOOL*, time_t*, int*)’
  282 | int get_user_line(LOGBOOK * lbs, char *user, char *password, char *full_name, char *email,
      |                                  ~~~~~~^~~~
make: *** [Makefile:140: auth.o] Error 1

thanks for your help.

Stefano


I see that they are generated probably automatically, but I guess you will run in all kinds of other problems in doing that.
> 
> I had a check with elogd. I found one buffer overflow once you delete an attachment with a long file name. I fixed that and committed the change.
> 
> Concerning your crash, I was not able to reproduce it. Used a 255 char long filename, and could NOT crash elogd. Maybe you have an oder version or some special config options which
> trigger that crash. Try with the newest git version and a minimal elogd.cfg configuration. Please also add line numbers during compilation (-g -o0 flags) so that I can better analyze
> your backtrace. Best would be if I could reproduce your error.
> 
> Best,
> Stefan
> 
> 
> 
> > Hi,
> >   I'm running 
> > elogd 3.1.4 built Jan 27 2021, 09:56:34 revision 395e101a
> > on an ubuntu server.
> > 
> > I have a crash when very long filename (200 chars) are attached to an logbook entry.
> > 
> > The uploading of the attachment works almost fine: the filename is truncated and the convert to thumbnail is not working (as a consequence, maybe) but the file is actually uploaded and can be 
> > downloaded correctly from the entry itself.
> > 
> > However, if I try to access the logbook list which contains that entry, I have a crash:
> > 
> > *** buffer overflow detected ***: terminated
> > Aborted (core dumped)
> > 
> > [backtrace is attached below]
> > 
> > The only way I found to solve this is to edit manually the log entry and delete the attachment from it.
> > 
> > Any suggestion how to solve this?
> > 
> > Thanks
> >   Stefano
> > 
> > 
> > *** buffer overflow detected ***: terminated
> > 
> > Program received signal SIGABRT, Aborted.
> > __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > 50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> > (gdb) bp
> > Undefined command: "bp".  Try "help".
> > (gdb) backtrace 
> > #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > #1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
> > #2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
> > #3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
> > #4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
> > #5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
> > #6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
> > #7  __GI__IO_default_xsputn (f=0x7ffffff36ca0, data=<optimized out>, n=241) at genops.c:370
> > #8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36ca0, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36de0, mode_flags=mode_flags@entry=6)
> >     at ../libio/libioP.h:948
> > #9  0x00007ffff7d57129 in __vsprintf_internal (
> >     string=0x7ffffff37120 
> > "../DAQ/220325_090630/j5K1OSy8XN9FRPriaBGOmMg3bih07CQKo68Sw6dskclxdOqKaTOsf2bX8UugSWn0s8zaAHe6VWiPcQVnmD8PM1tbQoVMr08dBrXKU2X2tBR4pJ3hlfxbKjspmcbiDTMy32eHIp6lFAVA9lppShmpiut4g4CtgDK3F2bOPzgzXEjPw
> > W0SJWG"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", args=args@entry=0x7ffffff36de0, mode_flags=6) at iovsprintf.c:95
> > #10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
> > #11 0x00005555555a939d in display_line ()
> > #12 0x00005555555ddc8a in show_elog_list ()
> > #13 0x00005555556010cf in interprete ()
> > #14 0x0000555555601a33 in decode_get ()
> > #15 0x000055555560461f in process_http_request ()
> > #16 0x0000555555607745 in server_loop ()
> > #17 0x000055555555a92c in main ()

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