Re: Crash report involving propagate and replies, posted by Stephen on Wed Jan 29 17:13:55 2014
|
| Stephen wrote: |
|
| Stefan Ritt 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?
|
Was a tricky problem. When you use "Propagate Attributes", a routine is called inside elogd which recursively goes through all replies. It uses quite some memory for temporary storage of attributes and attachments. So after a certain time you get a stack overflow since you run out of memory. Since the stack size is different under different operating systems, it was hard for me to reproduce it initially. Now I use some different memory (dynamic heap instead stack) which should fix the problem. Can you pull from GIT and give it a try?
/Stefan
|
Unfortunately, I am a little outside of my element when trying to compile it. I will ask around and see if someone here could give me a hand. Thanks for looking into this for me.
PS. If anyone else has managed to compile this could you give me a hand =)
|
This resolved the issue, thanks for the help. I have tested it on server machines and was able to go over 10 each time.
Thank you for resolving this issue for me. |
|
Re: Crash report involving propagate and replies, posted by Hung Dao on Mon Feb 3 22:45:10 2014
|
| Stephen wrote: |
|
| Stefan Ritt 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?
|
Was a tricky problem. When you use "Propagate Attributes", a routine is called inside elogd which recursively goes through all replies. It uses quite some memory for temporary storage of attributes and attachments. So after a certain time you get a stack overflow since you run out of memory. Since the stack size is different under different operating systems, it was hard for me to reproduce it initially. Now I use some different memory (dynamic heap instead stack) which should fix the problem. Can you pull from GIT and give it a try?
/Stefan
|
Unfortunately, I am a little outside of my element when trying to compile it. I will ask around and see if someone here could give me a hand. Thanks for looking into this for me.
PS. If anyone else has managed to compile this could you give me a hand =)
|
I was able to manage and compile the latest code from GIT. It runs fine so far. Just a hint, in order to compile successfully, there are some steps that you may need to modify your header file depend on how you store your mxml, krb5, OpenSSL files and directories. |
|
Re: Crash on attachment upload, posted by Dominic on Fri Sep 13 17:49:13 2024
|
I have the same problem with Ubuntu 24 on a Raspberry Pi system; it crashed whenever I uploade an attachment. Thanks!
| jaro mrazek wrote: |
|
I am on ubuntu 24.04.1, I needed to git clone, make and make install,
HEAD is 3fb85fa6 - (HEAD -> master, origin/master, origin/HEAD) Fixed compiler warning (3 weeks ago)
It crashes on every attachment: thank you. Jaro
root@vaio:~# systemctl status elogd
× elogd.service - The ELOG Server
Loaded: loaded (/usr/lib/systemd/system/elogd.service; enabled; preset: ena>
Active: failed (Result: core-dump) since Thu 2024-09-12 10:39:23 CEST; 3s a>
Duration: 5.402s
Docs: man:elogd(8)
man:elog(8)
Process: 724285 ExecStart=/usr/local/sbin/elogd -D -c /usr/local/elog/elogd.>
Main PID: 724286 (code=dumped, signal=ABRT)
CPU: 32ms
Sep 12 10:39:18 vaio systemd[1]: Starting elogd.service - The ELOG Server...
Sep 12 10:39:18 vaio elogd[724286]: elogd 3.1.5 built Sep 11 2024, 17:02:36
Sep 12 10:39:18 vaio elogd[724286]: revision 3fb85fa6
Sep 12 10:39:18 vaio elogd[724286]: File "/var/run/elogd.pid" exists, overwritin>
Sep 12 10:39:18 vaio systemd[1]: Started elogd.service - The ELOG Server.
Sep 12 10:39:18 vaio elogd[724286]: CKeditor detected
Sep 12 10:39:18 vaio elogd[724286]: ImageMagick detected
Sep 12 10:39:18 vaio elogd[724286]: Server listening on port 9000 ...
Sep 12 10:39:23 vaio systemd[1]: elogd.service: Main process exited, code=dumped>
Sep 12 10:39:23 vaio systemd[1]: elogd.service: Failed with result 'core-dump'.
root@vaio:~# systemctl restart elogd
|
|
Re: Crash on attachment upload, posted by Dominic on Tue Nov 5 15:44:57 2024
|
Does this issue occur only on Ubuntu systems? as I've experienced the same on my Raspberry Pi 5 running Ubuntu too ...
| jaro mrazek wrote: |
|
I am on ubuntu 24.04.1, I needed to git clone, make and make install,
HEAD is 3fb85fa6 - (HEAD -> master, origin/master, origin/HEAD) Fixed compiler warning (3 weeks ago)
It crashes on every attachment: thank you. Jaro
root@vaio:~# systemctl status elogd
× elogd.service - The ELOG Server
Loaded: loaded (/usr/lib/systemd/system/elogd.service; enabled; preset: ena>
Active: failed (Result: core-dump) since Thu 2024-09-12 10:39:23 CEST; 3s a>
Duration: 5.402s
Docs: man:elogd(8)
man:elog(8)
Process: 724285 ExecStart=/usr/local/sbin/elogd -D -c /usr/local/elog/elogd.>
Main PID: 724286 (code=dumped, signal=ABRT)
CPU: 32ms
Sep 12 10:39:18 vaio systemd[1]: Starting elogd.service - The ELOG Server...
Sep 12 10:39:18 vaio elogd[724286]: elogd 3.1.5 built Sep 11 2024, 17:02:36
Sep 12 10:39:18 vaio elogd[724286]: revision 3fb85fa6
Sep 12 10:39:18 vaio elogd[724286]: File "/var/run/elogd.pid" exists, overwritin>
Sep 12 10:39:18 vaio systemd[1]: Started elogd.service - The ELOG Server.
Sep 12 10:39:18 vaio elogd[724286]: CKeditor detected
Sep 12 10:39:18 vaio elogd[724286]: ImageMagick detected
Sep 12 10:39:18 vaio elogd[724286]: Server listening on port 9000 ...
Sep 12 10:39:23 vaio systemd[1]: elogd.service: Main process exited, code=dumped>
Sep 12 10:39:23 vaio systemd[1]: elogd.service: Failed with result 'core-dump'.
root@vaio:~# systemctl restart elogd
|
|
|
Re: Crafted URL causes elog to coredump, posted by Stefan Ritt on Mon Mar 6 14:04:12 2006
|
| Steve Jones wrote: | While playing with TOP GROUP I managed to get elog 2.6.1 1660 on Solaris 9 to coredump. Since I didn't really understand TOP GROUP I tried a URL where I had http://elog.server.com/topgroupname/logbookname. Putting that logbookname at the end caused elog to dump.
Can this be reproduced by others? |
No. This forum has the "elog" as the top group, "Forum" as the logbook, so if I write
http://midas.psi.ch/elogs/elog/Forum
it does not crash. |
|
Re: Crafted URL causes elog to coredump, posted by Steve Jones on Mon Mar 6 17:35:52 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | While playing with TOP GROUP I managed to get elog 2.6.1 1660 on Solaris 9 to coredump. Since I didn't really understand TOP GROUP I tried a URL where I had http://elog.server.com/topgroupname/logbookname. Putting that logbookname at the end caused elog to dump.
Can this be reproduced by others? |
No. This forum has the "elog" as the top group, "Forum" as the logbook, so if I write
http://midas.psi.ch/elogs/elog/Forum
it does not crash. |
|
|
Re: Crafted URL causes elog to coredump, posted by Stefan Ritt on Mon Mar 6 17:45:18 2006
|
No, the above link just works fine, just click it. |
|
Re: Crafted URL causes elog to coredump, posted by Steve Jones on Mon Mar 6 18:04:39 2006
|
| Stefan Ritt wrote: |
No, the above link just works fine, just click it. |
| Quote: | I was afraid to try  . Ok, then the issue *might* be rev 1660 or perhaps the fact that compiled under Solaris it does this. Any suggestions on how to find out? |
|
|