The server is crached because the author field was accidentally filled with a long string due to an automated (remote) script:

“
Author: The ion getter pump has successfully recovered and appears to be operating steadily once more. Consequently, I proceeded with sputtering to obtain an XPS survey scan of the Au sample.  Initially, the stability of the X-ray function was compromised, leading to multiple interruptions. Subsequently, an unexplained issue arose regarding the collection of counts on the channeltron detector. Additionally, the emission current exhibited fluctuations. Fortunately, it seems that we have addressed and resolved the previous issues.  In the image below, two XPS survey spectra are presented. The spectrum highlighted with a red line corresponds to the AlKa source, which was selected using the AlKa button. Conversely, the spectrum with a black line represents the MgKa source. In both cases, the energy configuration was set to 1486.7 eV. It's worth noting that the 1050 eV peak in both spectra corresponds to the Au4f state, with an energy displacement of 961.7 eV due to X-ray ghost lines caused by O contamination (84+961.7). It has come to my attention that the Mg source appears to have oxidized, a phenomenon we've observed before.  Moreover, it's important to highlight that the difference between the peaks in the low binding energy region is approximately 100 eV, not the expected 233 eV (considering the energy difference between magnesium and aluminum). This observation holds true for both cases where the same energy setting was used. Additionally, the energy of the Au4f peakSotirios Tsatso
“

Instead of just "Sotirios Tsatso". 

So it had nothing to do with the cookies etc.. But when the item created in this way was called up, the system crashed:

[248459.853246] elogd_misc[8407]: segfault at 561725164a4e ip 00007f8210c02854 sp 00007ffdcb92b338 error 4 in libc-2.31.so[7f8210a99000+178000]
[248459.853251] Code: 7f 07 c5 fe 7f 4f 20 c5 fe 7f 54 17 e0 c5 fe 7f 5c 17 c0 c5 f8 77 c3 48 39 f7 0f 87 ab 00 00 00 0f 84 e5 fe ff ff c5 fe 6f 26 <c5> fe 6f 6c 16 e0 c5 fe 6f 74 16 c0 c5 fe 6f 7c 16 a0 c5 7e 6f 44

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 Stefano,

well, why in heaven's name do you run 200+ chars file names? 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 ()

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 ()

• Copy over the *.log files from one Elog to the other. Make sure not to have entries with the same ID twice then.
  
• Set-up mirroring between two servers. This ensures a 1:1 copy of the server
  
• Export entries in CSV format (comma-separated-values) via 'Find', 'Mode = CSV', and do a 'CSV import' on the other side.
  

• If you want to import entries which contain replies, it only works if import them into an empty logbook, where the imported entries can obtain the same entry IDs as in the original logbook.
  
• The names of possible attachments are correctly imported, but not the files themselves. These you have to copy by hand.