ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68781
|
Wed Apr 11 18:14:35 2018 |
| Michael Kelsey | kelsey@slac.stanford.edu | Bug report | Mac OSX | 3.1.3 | "Slow script" problem posting/editing from Safari -- browser hangs, times out | Hello! The CDMS collaboration is using e-Log as one of it's issue tracking systems. In the last few months, I have noticed a problem when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4): The [Submit] button triggers a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding all of my edits, uploads, whatever. This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.
Now, I am also seeing the same problems with Firefox, but at the "occasional" level. The difference is that Firefox produces some diagnostic information, which is why I'm posting here. When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:
Warning: unresponsive script
A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.
Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30
[] Don't ask me again
[Debug script] [Stop script] [Continue]
If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:
16 var in_asend = false;
17
18 function chkform()
19 {
20 if (last_key == 13) {
21 var ret = confirm('Really submit this entry?');
22 if (!ret) {
23 last_key = 0;
24 return false;
25 }
26 }
27
28 if (autoSaveTimer != null)
29 clearTimeout(autoSaveTimer);
30 while (in_asend); <=== This is the stuck line
31 submitted = true;
32 return true;
33 }
I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.
Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve? |
68792
|
Fri May 4 14:43:35 2018 |
| Joseph McKenna | joseph.mckenna@cern.ch | Bug report | Linux | 2.9.2 | Elog ID entry bug at >99999 entries | 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 |
Attachment 1: sequencer_events.png
|
|
68802
|
Fri May 18 00:57:33 2018 |
| Tom Roberts | tom.roberts@iit.edu | Bug report | Windows | latest | elogd service crashes after windows update | 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? |
68830
|
Tue Aug 7 10:53:45 2018 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Info | Linux | elog-3.1.3 | Problem with eloglang.german_UTF8 | I had a problem with restarting ELOG since about a year, and finally I found the culprit. I just want to share it here, to prevent anyone else to make the same mistake,
Apparently the files resources/eloglang.* are rather sensitive to the syntax. But it doesn't tell you: no warning or error message comes up.
The file eloglang.german_UTF8 contains some "missing translations" at the end - and it looks like they produce some problems.
If you don't follow the instructions to create eloglang.german_UTF8 from eloglang.german, but use the file as it is, then the language handling will be corrupted:
some (very few) language strings will point into some void and display garbage strings.
In very rare cases this will even crash "elogd", in all other cases it will confuse your users.
Sometimes ELOG commands like "?Cmd=New" were affected, which makes ELOG unusable.
What made it very hard to debug was the fact that with every restart a different string was affected.
Everything looked fine, and later you see a string in the configuration page is wrong. Restarting fixed that string, but then some other string is gone.
So if you see such a behaviour, check your language file for "unusual syntax".
I haven't checked if the problem is limited to UTF8 - I only saw the problem with the eloglang.german_UTF8 file.
Cheers, Andreas |
68839
|
Tue Sep 11 19:46:40 2018 |
| Allen Tuttle | AllenEmail@wavecable.com | Bug report | Linux | 3.1.3 | Compile issues on Fedora withe current elog source | 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? |
68851
|
Fri Oct 26 08:56:59 2018 |
| Wenhao Huang | whyellow@mail.sdu.edu.cn | Bug report | Linux | ELOG V3.1.2-bd7 | messy code for chinese charactor | The Chinese character appears messy code. The encoding way is the default utf-8. How can I solve this problem? |
68858
|
Mon Nov 26 17:32:31 2018 |
| Yanick Vachon | yvachon@materiauxblanchet.ca | Request | Windows | 3.1.2 | Need to change port 25 | Hi,
We've made changes in our network and now we have to use port 587 instead of port 25, how can i edit that parameter?
Thanks |
68862
|
Tue Nov 27 20:06:17 2018 |
| Yanick Vachon | yvachon@materiauxblanchet.ca | Bug report | Windows | 3.1.2 | French Language | Hi,
When i set Language = French in global config it works in french until i logout, after i can't login anymore, even if i enter my user and password i always stay at the login window, the only way to login again is to edit the Elogd.cfg file in Elog directory, remove the Language = french and save then i can login in and work normally in english version.
Thanks. |
|