Hi Stefan,

I've seen that ELOG is build now with gcc-c++ now, so i tried to check rpmbuild script with all options. It seems that ldap api is different with c++ (quick search : https://www.openldap.org/lists/openldap-software/200706/msg00177.html) and elogd can not been build anymore with ldap support. :-(

# make
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -DHAVE_PAM -c -o mxml.o mxml/mxml.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -DHAVE_PAM -w -c -o crypt.o src/crypt.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -DHAVE_PAM -c -o strlcpy.o mxml/strlcpy.cxx
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -DHAVE_PAM -o elog src/elog.cxx mxml.o crypt.o strlcpy.o -lssl -lkrb5 -lldap -llber -lpam -llber
c++ -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Wno-unused-result -Imxml -DHAVE_SSL -DHAVE_KRB5 -DHAVE_LDAP -DHAVE_PAM -w -c -o auth.o src/auth.cxx
src/auth.cxx: In function ‘int auth_verify_password_ldap(LOGBOOK*, const char*, const char*, char*, int)’:
src/auth.cxx:283:60: erreur: ‘ldap_simple_bind_s’ was not declared in this scope
    bind = ldap_simple_bind_s(ldap_ld, ldap_bindDN, password);
                                                            ^
src/auth.cxx:290:26: erreur: ‘ldap_unbind’ was not declared in this scope
       ldap_unbind(ldap_ld);
                          ^
src/auth.cxx:295:23: erreur: ‘ldap_unbind’ was not declared in this scope
    ldap_unbind(ldap_ld);
                       ^
src/auth.cxx: In function ‘int ldap_adduser_file(LOGBOOK*, const char*, const char*, char*, int)’:
src/auth.cxx:323:60: erreur: ‘ldap_simple_bind_s’ was not declared in this scope
    bind = ldap_simple_bind_s(ldap_ld, ldap_bindDN, password);
                                                            ^
src/auth.cxx:330:26: erreur: ‘ldap_unbind’ was not declared in this scope
       ldap_unbind(ldap_ld);
                          ^
src/auth.cxx:358:26: erreur: ‘ldap_unbind’ was not declared in this scope
       ldap_unbind(ldap_ld);
                          ^
src/auth.cxx:369:62: erreur: ‘ldap_get_values’ was not declared in this scope
          if((values = ldap_get_values(ldap_ld,entry,attribute)) != NULL ) {
                                                              ^
src/auth.cxx:378:35: erreur: ‘ldap_value_free’ was not declared in this scope
             ldap_value_free(values);
                                   ^
src/auth.cxx:386:23: erreur: ‘ldap_unbind’ was not declared in this scope
    ldap_unbind(ldap_ld);
                       ^
src/auth.cxx: In function ‘int elog_conv(int, const pam_message**, pam_response**, void*)’:
src/auth.cxx:451:59: erreur: invalid conversion from ‘void*’ to ‘pam_response*’ [-fpermissive]
    if((*resp = calloc(num_msg, sizeof(struct pam_response))) == NULL)
                                                           ^
src/auth.cxx:456:33: erreur: invalid conversion from ‘void*’ to ‘const char*’ [-fpermissive]
    if(!(resptok = strdup(my_data))) {
                                 ^
In file included from src/elogd.h:46:0,
                 from src/auth.cxx:30:
/usr/include/string.h:172:14: erreur:   initializing argument 1 of ‘char* strdup(const char*)’ [-fpermissive]
 extern char *strdup (const char *__s)
              ^
src/auth.cxx: In function ‘int auth_verify_password(LOGBOOK*, const char*, const char*, char*, int)’:
src/auth.cxx:593:73: erreur: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
          if (get_user_line(lbs, user, NULL, NULL, NULL, NULL, NULL, NULL) == 2) {
                                                                         ^
In file included from src/auth.cxx:30:0:
src/elogd.h:282:5: erreur:   initializing argument 2 of ‘int get_user_line(LOGBOOK*, char*, char*, char*, char*, BOOL*, time_t*, int*)’ [-fpermissive]
 int get_user_line(LOGBOOK * lbs, char *user, char *password, char *full_name, char *email,
     ^
make: *** [auth.o] Erreur 1
 

Regards,

Laurent

Something is not right with the elog account activation, I get the email
for "Registration request for ELOG logbook "haicu"", but when I follow the given URL,
I get "Invalid activation code". Account activation requests go to two people,
so maybe the other one already activate this user, in which case I expect a message "user already active".
When I check the elog config, I see that the user indeed is already active. And if I rerun
this URL I still get "Invalid activation code", and this time I definitely expect "user already active".

https://daq00.triumf.ca/elog-haicu/haicu/?cmd=Activate&new_user_name=fujiwara&code=-1904103410&unm=Olchansk

K.O.

we had an elog with only one logbook and one password file,
we added a second logbook with a second password file and everything broke.

specifically, login to the original logbook stopped working,
username and password is accepted, elog.log says "user accepted", but I am presented
with the login dialog again, ad infinitum, and cannot access the elog.

solution seems to be to "delete all cookies" (which is excessive,
google chrome wants to delete all cookies for *.triumf.ca,
which will log me out from everywhere I am logged in and probably
erase/reset web site preferences everywhere).

manually deleting just the elog session cookie also seems to work, though.

this suggests that there is a bug in elog, where on successful login,
it fails to create a new authentication cookie, but reuses an old
cookie, which is no longer valid, for whatever reason (that would
be a different bug, why adding one more logbook invalidates
existing logins?).

K.O.

> Something is not right with the elog account activation...

I did a test:
- register as new user "test", web page says "request for approval sent..." (good)
- check elog config, user "test" is present, "active" set to "no" (good)
- open the "approve/activate" URL, get "Invalid activation code" (should say: "activated successfully!")
- check elog config, user "test" now has "active" set to "yes" (good, "approve/activate" URL worked)
- open the "approve/activate" URL again, again "Invalid activation code" (should say: "already activated!")

additional test:
- from the elog config, user "test", set active to "no", save.
- open the "approve/activate" URL, get "Invalid activation code" (good, this time)
- check elog config, user "test" is still inactive (good)

So it looks like the "approve/activate" URL works correctly - only the first time it is accessed - but
returns wrong message "invalid activation code" instead of "success".

K.O.
 

"file not found" should return http code 404. elogd returns code 200 together
with a page containing text "404 not found". This pollutes the browser cache
with wrong content (in this case, we are trying to load a css file, and the browser
is trying to use text "404 not found" as if it were a css. bad. file not found
should return http code 404. K.O.

in example below, response "HTTP/1.1 200 Document follows" should be "HTTP/1.1 404 ..."

to reproduce, through the https proxy:

daq00:~$ curl -v https://daq00.triumf.ca/elog-midas/Midas/zzz.css
*   Trying 142.90.111.168:443...
...
> GET /elog-midas/Midas/zzz.css HTTP/1.1
...
< HTTP/1.1 200 Document follows
< Date: Thu, 17 Mar 2022 23:40:04 GMT
< Server: ELOG HTTP 3.1.4-2e1708b5
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Content-Type: text/html;charset=ISO-8859-1
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< 
<!DOCTYPE html>
<html><head>
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<title>404 Not Found</title>
<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body><h1>404 Not Found</h1>
The requested file <b>zzz.css</b> was not found on this server<p>
* Connection #0 to host daq00.triumf.ca left intact
daq00:~$ 

directly:

daq00:~$ curl -v http://localhost:9080/Midas/zzz.css
*   Trying 127.0.0.1:9080...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9080 (#0)
> GET /Midas/zzz.css HTTP/1.1
> Host: localhost:9080
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 Document follows
< Server: ELOG HTTP 3.1.4-2e1708b5
< Content-Type: text/html;charset=ISO-8859-1
< Connection: Close
< 
<!DOCTYPE html>
<html><head>
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<title>404 Not Found</title>
<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body><h1>404 Not Found</h1>
The requested file <b>zzz.css</b> was not found on this server<p>
* Closing connection 0
daq00:~$ 

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