ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67630
|
Wed Nov 27 15:22:37 2013 |
| Stephen | swgallman@bpa.gov | Bug report | Windows | 2.9.2 | Re: Crash report involving propagate and replies |
David Pilgram wrote: |
Stephen wrote: |
Using Elog 2.9.2
Elog crashes when making 10 replies, I narrowed the crash down to the Propagate Attributes setting.
I have an attribute "Status" that can be toggled between "Open" and "Closed" and that propagates all replies. On the 10th reply the application crashed, this is repeatable 100% of the time. Without the propagate option everything works fine.
Attached is my config file parsed down.
Is there a way around this, or is there a way on reply to change the attribute of the log note you replied to from open to closed without using the propagate option?
|
Hi Stephen,
I see that you don't allow branching in your threads. Why do you need to propagate the Status throughtout the thread? Why not just mark the latest entry and (incase it is necessary) 'collapse to last = 1'
I'm not saying that the bug (if bug it is, rather than a preset limitation) you've found should not be fixed, but I'm puzzled as to why you happen to use the feature. I can see the point if an initial entry provides a whole tree of branches (and a limit of 10 is rather limiting). OK, I know if it is historic, it cannot easily be changed because of other users. Or if some users will primarily be responding to emails rather viewing the logbook via a browser. I'm a single (ab)user elog system myself, so I'm very tolerant of changing how elog works if it offers an improvement.
|
Thank you for the reply, the not allowing branching was added during the troubleshooting phase of the crashing. Initially I thought the branches caused the issue because crashing only occured on log notes that branched as I only saw the crash on notes that branched, this proved not to be the case. Even with branches the system will crash once there are 10 replies in the note with propagate on.
As for use case, with a few users I needed a way to represent a note as open so that the next person knew work still needed to be done. Once work was completed all notes close, the reason for not using edit is so I have a clear record of what happened (although I may need to change to edit if 10 is the max). I will experiment with the collapse to last to see how it looks. Any other suggestions would be helpful. |
67631
|
Mon Dec 2 09:27:35 2013 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Windows | 2.9.2 | Re: Crash report involving propagate and replies |
Stephen wrote: |
Using Elog 2.9.2
Elog crashes when making 10 replies, I narrowed the crash down to the Propagate Attributes setting.
I have an attribute "Status" that can be toggled between "Open" and "Closed" and that propagates all replies. On the 10th reply the application crashed, this is repeatable 100% of the time. Without the propagate option everything works fine.
Attached is my config file parsed down.
Is there a way around this, or is there a way on reply to change the attribute of the log note you replied to from open to closed without using the propagate option?
|
Hi Stephen,
I've just checked that elogd can handle "Propagate Attributes" for more than 10 replies without crashing (I've attached my config, you can see if it works for you.)
Therefore it has to be something else in your configuration that causes this behaviour, or a combination of things.
Could you strip off the configuration further, that it contains the minimal content to cause elogd to crash? Or can you use a debugger on your system?
Cheers
Andreas
⇄
English (auto-detected) » English
⇄
English (auto-detected) » English
⇄
English (auto-detected) » English
⇄
English (auto-detected) » English
⇄
English (auto-detected) » English
⇄
English (auto-detected) » English
|
67632
|
Mon Dec 2 09:58:42 2013 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Windows | 2.9.2 | Re: Crash report involving propagate and replies |
Stephen wrote: |
Using Elog 2.9.2
Elog crashes when making 10 replies, I narrowed the crash down to the Propagate Attributes setting.
I have an attribute "Status" that can be toggled between "Open" and "Closed" and that propagates all replies. On the 10th reply the application crashed, this is repeatable 100% of the time. Without the propagate option everything works fine.
Attached is my config file parsed down.
Is there a way around this, or is there a way on reply to change the attribute of the log note you replied to from open to closed without using the propagate option?
|
⇄
English (auto-detected) » English
Bad news: I cannot reproduce your problem with the latest elog version 2.9.2 (e7ba466) on scientific linux 6.0
I had to remove some lines in your config, since I don't have your password file.
I'll attach the config file, please have a look if it crashes on your server with the latest elogd version.
⇄
English (auto-detected) » English
Andreas
⇄
English (auto-detected) » English
⇄
English (auto-detected) » English
|
67633
|
Mon Dec 2 23:02:45 2013 |
| Stephen | swgallman@bpa.gov | Bug report | Windows | 2.9.2 | Re: Crash report involving propagate and replies |
Andreas Luedeke wrote: |
Stephen wrote: |
Using Elog 2.9.2
Elog crashes when making 10 replies, I narrowed the crash down to the Propagate Attributes setting.
I have an attribute "Status" that can be toggled between "Open" and "Closed" and that propagates all replies. On the 10th reply the application crashed, this is repeatable 100% of the time. Without the propagate option everything works fine.
Attached is my config file parsed down.
Is there a way around this, or is there a way on reply to change the attribute of the log note you replied to from open to closed without using the propagate option?
|
Bad news: I cannot reproduce your problem with the latest elog version 2.9.2 (e7ba466) on scientific linux 6.0
I had to remove some lines in your config, since I don't have your password file.
I'll attach the config file, please have a look if it crashes on your server with the latest elogd version.
Andreas
|
Thanks for the reply, I tried the very basic cfg and the second one you offered. Running 2.9.2-2475 on a Windows 2008 R2 V.Server, I still crashed on attempt 10 never fail. Windows detects the failure and gives this message:
Faulting application name: elogd.exe, version: 0.0.0.0, time stamp: 0x51248707
Faulting module name: elogd.exe, version: 0.0.0.0, time stamp: 0x51248707
Exception code: 0xc00000fd
Fault offset: 0x00065127
Faulting process id: 0x340
Faulting application start time: 0x01ceefa87fea0aea
Faulting application path: D:\ELOG\elogd.exe
Faulting module path: D:\ELOG\elogd.exe
Report Id: ceccc3da-5b9b-11e3-80f1-5ac95c924b0b
It only happens when propagate is on, I have to be missing some security setting in Windows maybe? Don't know if that helped at all, but I'm out of ideas. |
67634
|
Tue Dec 3 11:30:43 2013 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Windows | 2.9.2 | Re: Crash report involving propagate and replies |
Stephen wrote:
|
Andreas Luedeke wrote:
|
Stephen wrote:
|
Using Elog 2.9.2
Elog crashes when making 10 replies, I narrowed the crash down to the Propagate Attributes setting.
I have an attribute "Status" that can be toggled between "Open" and "Closed" and that propagates all replies. On the 10th reply the application crashed, this is repeatable 100% of the time. Without the propagate option everything works fine.
Attached is my config file parsed down.
Is there a way around this, or is there a way on reply to change the attribute of the log note you replied to from open to closed without using the propagate option?
|
Bad news: I cannot reproduce your problem with the latest elog version 2.9.2 (e7ba466) on scientific linux 6.0
I had to remove some lines in your config, since I don't have your password file.
I'll attach the config file, please have a look if it crashes on your server with the latest elogd version.
Andreas
|
Thanks for the reply, I tried the very basic cfg and the second one you offered. Running 2.9.2-2475 on a Windows 2008 R2 V.Server, I still crashed on attempt 10 never fail. Windows detects the failure and gives this message:
Faulting application name: elogd.exe, version: 0.0.0.0, time stamp: 0x51248707
Faulting module name: elogd.exe, version: 0.0.0.0, time stamp: 0x51248707
Exception code: 0xc00000fd
Fault offset: 0x00065127
Faulting process id: 0x340
Faulting application start time: 0x01ceefa87fea0aea
Faulting application path: D:\ELOG\elogd.exe
Faulting module path: D:\ELOG\elogd.exe
Report Id: ceccc3da-5b9b-11e3-80f1-5ac95c924b0b
It only happens when propagate is on, I have to be missing some security setting in Windows maybe? Don't know if that helped at all, but I'm out of ideas.
|
Can you compile elog? Then I would suggest that you download the latest version from GIT an recompile it. You'll find help for that here: https://midas.psi.ch/elog/download.html
I have no experience with compilation on Windows (I try not to touch it, and if I have to I use a long stick ;-)
⇄
English (auto-detected) » English
|
67640
|
Thu Dec 19 19:42:48 2013 |
| John Haggerty | haggerty@bnl.gov | Bug report | Mac OSX | 2.9.2-2475 | ELOG on Chrome on MacOS? | In the past couple of days, I seem to have developed a problem with making entries into elog's displayed with Chrome (the latest, 31.0.1650.63) on
Mac OS (10.9.1, the latest). The problem occurs with attempting to edit or enter HTML encoded pages with fckedit; although pages render correctly
in list mode, if you try to edit or enter an entry, the page is blank, the cursor is missing, you can't see text or type new text. I ran elogd -v by hand,
and there were no obvious problems, and I looked at the developer consoles in Chrome, and the only place I see any hint of what the problem might
be is the Javascript console which says this:
event.returnValue is deprecated. Please use the standard event.preventDefault() instead.
Uncaught SecurityError: Blocked a frame with origin "http://localhost:8080" from accessing a frame with origin "chrome-
extension://pioclpoplcdbaefihamjohnefbikjilc". The frame requesting access has a protocol of "http", the frame being accessed has a protocol of
"chrome-extension". Protocols must match.
fckeditorcode_gecko.js:36
It works ok in Safari, but it would be nice to use Chrome, and it was working ok until recently. I don't think the problem occurred when I updated to
Mac OS 10.9.1, but I don't keep careful track of the Chrome version. It's not critical, but I pretty much exhausted what I knew how to debug. I have
close to the latest elog (2.9.2-2455), although I see the same phenomenon on this elog (.2.9.2-2475) and I think it's related to this thread:
http://productforums.google.com/forum/#!msg/maps/hQhwWA56NbA/2XL35dU7le4J
I tried the prescription in the October 22 entry, but it didn't seem to help, although I wasn't sure I had really tested it with compressed javascript and
cache and what have you. |
67641
|
Fri Dec 20 09:25:08 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 2.9.2-2475 | Re: ELOG on Chrome on MacOS? | > In the past couple of days, I seem to have developed a problem with making entries into elog's displayed with Chrome (the latest, 31.0.1650.63) on
> Mac OS (10.9.1, the latest). The problem occurs with attempting to edit or enter HTML encoded pages with fckedit; although pages render correctly
> in list mode, if you try to edit or enter an entry, the page is blank, the cursor is missing, you can't see text or type new text.
That's strange. I just tried myself (by accident I have the same versions of Chrome and OSX) and it just worked fine. The fckedit code has not change a long time, so I guess it's not related to the exact version of
elogd. Anyhow I want to switch to ckedit when I get some time, which maybe fixes the problem. What happens if you try to write in this forum, do you have the same problem? Sometime the fcdedit code take
quite long time to load when accessed remotely. If your browser gives up, you might hat to click on "reload". In chrome there is also the "Developer tools" window, which shows you all HTTP requests and
responses on the network. Otherwise I run out of ideas what could be different for you compared to me.
Cheers,
Stefan |
67642
|
Fri Dec 20 13:38:09 2013 |
| John Haggerty | haggerty@bnl.gov | Bug report | Mac OSX | 2.9.2-2475 | Re: ELOG on Chrome on MacOS? | > > In the past couple of days, I seem to have developed a problem with making entries into elog's displayed with Chrome (the latest, 31.0.1650.63) on
> > Mac OS (10.9.1, the latest). The problem occurs with attempting to edit or enter HTML encoded pages with fckedit; although pages render correctly
> > in list mode, if you try to edit or enter an entry, the page is blank, the cursor is missing, you can't see text or type new text.
>
> That's strange. I just tried myself (by accident I have the same versions of Chrome and OSX) and it just worked fine. The fckedit code has not change a long time, so I guess it's not related to the exact version of
> elogd. Anyhow I want to switch to ckedit when I get some time, which maybe fixes the problem. What happens if you try to write in this forum, do you have the same problem? Sometime the fcdedit code take
> quite long time to load when accessed remotely. If your browser gives up, you might hat to click on "reload". In chrome there is also the "Developer tools" window, which shows you all HTTP requests and
> responses on the network. Otherwise I run out of ideas what could be different for you compared to me.
>
> Cheers,
> Stefan
Later on, I tried the prescription pointed to in that thread that says in scripts/fckeditor/editor/js/fckeditorcode_gecko.js to replace
FCKTools.FixDocumentParentWindow = function(A){ if (A.document) A.document.parentWindow=A; for (var i=0;i<A.frames.length;i++) FCKTools.FixDocumentParentWindow(A.frames[i]);};
with:
FCKTools.FixDocumentParentWindow = function(A){try{ if (A.document) A.document.parentWindow=A;} catch(e){};for (var i=0;i<A.frames.length;i++) FCKTools.FixDocumentParentWindow(A.frames[i]);};
and after I got all my brackets straight, my pages were visible. I'm still not sure when this turned up, since I use my elog every day (hour) and so I'd hardly miss it when I upgraded various things, although I don't watch Chrome updating itself that closely.
Have a good holiday! |
|