Re: Elog ID entry bug at >99999 entries, posted by Joseph McKenna on Tue May 8 16:17:28 2018
|
Thank you all for your kind responses. Please consider this thread resolved: no bug in elog
| Chris Rasmussen wrote: |
|
ah yes, that was a helpful clue. Our elogd.cfg file led me to a .js file which redefines the ID to the elog:SequencerEvents/XXXXX format and it indeed had a silly hard coded length of that string.
Since I am pretty sure this is our code, I think it is safe to say that this is not a bug in the elog
| Andreas Luedeke wrote: |
|
Well, in my example the ID link worked just fine.
There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.
Cheers, Andreas
| Chris Rasmussen wrote: |
|
Hi Andreas, I'm working on the same experiment as Joseph who submitted the bug report.
You are right, IDs greater than 10^5 are created no problem. The issue is with the internal elog link, in this case of the form elog:SequencerEvents/XXXXX The link generated uses only the first 5 digits of the message ID, and therefore links to the wrong message. In the two attachments you can see our sequencer event number 100098, first displaying the message where all of the ID is displayed and secondly in "full" view of the elog front page. Here, the "ID" column contains a link with the string: elog:SequencerEvents/10009. Our problem is that we often use this string to paste into other elogs and generate a link to the sequencer event message. However, since the string uses too few digits, we end up with a link to the wrong message
| Andreas Luedeke wrote: |
|
I am not sure I understand your bug report.
I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?
Cheers, Andreas
| Joseph McKenna wrote: |
|
We have a possible bug with elog that the ID for an elog entry at over 99,999 entires reads as 10,000...
68792/1 Illistrates the problem, we use this ID often to cross reference from out datalog...
Is this a know bug we can find a fix for? We are using: elogd 2.9.2 built Jul 14 2015, 18:58:06 revision
|
|
|
|
|
|
elogd service crashes after windows update, posted by Tom Roberts on Fri May 18 00:57:33 2018
|
We have been using elog on Windows 10 for a long time. Today, after a Windows update, the elogd service started crashing (error 1067, unexpected termination). It ran fine just before the Windows update (which took > 1 hour, so it was a major one). Uninstalling and re-installing did not help, including replacing my elogd.cfg with the default. Installing on another PC (that also has this update) fails in the same way. I have a good backup of my logbook.
Any suggestions? |
|
Compile issues on Fedora withe current elog source, posted by Allen Tuttle on Tue Sep 11 19:46:40 2018
|
Tried compiling on FC27 and 28, both result in binaries but with serious issues; writing data larger than then allowed.
Example output:
make
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -c -o mxml.o mxml/mxml.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -w -c -o crypt.o src/crypt.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -w -c -o regex.o src/regex.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -c -o strlcpy.o mxml/strlcpy.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -o elog src/elog.c mxml.o crypt.o regex.o strlcpy.o -lssl
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -w -c -o auth.o src/auth.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -DHAVE_SSL -o elogd src/elogd.c auth.o mxml.o crypt.o regex.o strlcpy.o -lssl
src/elogd.c: In function ‘el_retrieve’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve_attachment.part.30’:
src/elogd.c:4764:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4764:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_submit.constprop’:
src/elogd.c:4894:29: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4894:7: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_submit’:
src/elogd.c:4894:29: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4894:7: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve.constprop’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve.constprop’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘el_retrieve.constprop’:
src/elogd.c:4503:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘show_download_page’:
src/elogd.c:14775:32: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 1 and 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
src/elogd.c:14775:10: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/elogd.c: In function ‘search_last_reply’:
.
.
.
Anyone aware of a cure? |
Re: Compile issues on Fedora withe current elog source, posted by Stefan Ritt on Wed Sep 12 11:10:18 2018
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan |
|
Re: Compile issues on Fedora withe current elog source, posted by Allen Tuttle on Wed Sep 12 15:20:11 2018
|
I don't see the update on elog/download/tar/.
Do you keep builds elsewhere, perhaps on get or sourceforge?
| Stefan Ritt wrote: |
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan
|
|
|
Re: Compile issues on Fedora withe current elog source, posted by Allen Tuttle on Wed Sep 12 15:25:07 2018
|
I would like to try the new code, I don't see it on elog/download/tar/.
Do you keep updates elsewhere like on get or sourceforge?
| Stefan Ritt wrote: |
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan
|
|
|
Re: Compile issues on Fedora withe current elog source, posted by Allen Tuttle on Wed Sep 12 15:57:31 2018
|
A quick test suggests I can't just replace sprintf with snprintf.
Original error:
src/elogd.c:4503:4: note: ‘sprintf’ output between 1 and 542 bytes into a destination of size 256 [-Wformat-overflow=]
sprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~
New error:
src/elogd.c:4503:24: warning: passing argument 2 of ‘snprintf’ makes integer from pointer without a cast [-Wint-conversion]
snprintf(file_name, "%s%s%s", lbs->data_dir, lbs->el_index[index].subdir, lbs->el_index[index].file_name);
^~~~~~~~
In file included from src/elogd.h:42:0,
from src/elogd.c:38:
/usr/include/stdio.h:340:12: note: expected ‘size_t {aka long unsigned int}’ but argument is of type ‘char *’
extern int snprintf (char *__restrict __s, size_t __maxlen,
| Allen Tuttle wrote: |
|
I would like to try the new code, I don't see it on elog/download/tar/.
Do you keep updates elsewhere like on get or sourceforge?
| Stefan Ritt wrote: |
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan
|
|
|
|
Re: Compile issues on Fedora withe current elog source, posted by Andreas Luedeke on Wed Sep 12 20:52:22 2018
|
Stefan said "code is commited": that means you can download the latest version from https://bitbucket.org/ritt/elog, as described in https://elog.psi.ch/elog/download.html, and then compile it. Clear now?
| Stefan Ritt wrote: |
|
This warning is triggered by the use of the sprintf() funciton, which can write beyond the boundary of the destination string. I replaced it by snprintf(), which should make the compiler happy. Code is committed. Unfortuantely I have no FC27 here, so if there is still some waring with the current code, please post the full warning list here.
Stefan
|
|
|