Re: elogd crashes when running mirror cron with SSL and KRB5, posted by Andreas Luedeke on Fri Jun 3 12:06:20 2011
|
> When I run a mirror server and both logbooks using SSL/KRB5 then the cron job causes a segmentation fault.
>
> I haven't tried to check it with a simple configuration yet.
> My set-up: two elogd on same server, one running "german" on port 444, the other "english" on port 445.
> Both are behind an apache webserver configured reverse proxy, to hide the ports for external access.
> I'll try to reproduce the fault with a "minimal configuration" soon and report again.
>
I've tried to test a simpler configuration on my local PC but failed:
all simple set-ups I've tried worked fine.
I found that the mirror cron synchronization works fine in my production set-up when I remove the line:
Mirror user = luedeke
But I can have this line in my simple test set-up and it still works fine.
Anyway: bugs closed for me. |
segmentation fault when "restrict edit" is used and "new" is allowed for anonymous users, posted by Andreas Luedeke on Mon Jun 20 05:31:31 2011 
|
The simple config file below produces a segmentation fault when elogd is started,
http://localhost/Test/?cmd=New
is opened in the browser and then e.g. "Entry" is switched to "Problem".
gdb shows the following output:
(gdb) run -c /usr/local/elog/elogd.cfg
Starting program: /usr/local/sbin/elogd -c /usr/local/elog/elogd.cfg
elogd 2.9.0 built Jun 20 2011, 04:57:23 revision 2414
Falling back to default group "elog"
Falling back to default user "elog"
FCKedit detected
Falling back to default group "elog"
Falling back to default user "elog"
ImageMagick detected
Indexing logbooks ... done
Server listening on port 80 ...
Program received signal SIGSEGV, Segmentation fault.
0x080a2940 in get_user_line (lbs=0xae3c1c0, user=0x0, password=0x0, full_name=0xbfca1690 "", email=0x0, email_notify=0x0,
last_logout=0x0, inactive=0x0) at src/elogd.c:24864
24864 if (!str[0] || !user[0])
|
Re: segmentation fault when "restrict edit" is used and "new" is allowed for anonymous users, posted by Stefan Ritt on Mon Jun 20 17:53:58 2011
|
| You are the first one allowing guests to enter new entries, so this probes a code path which was never used before. I fixed the crash in SVN revision 2416, but it might be that there are more issues with that. Just keep reporting. |
|
Elog crashes with URL find npp=0, posted by Andreas Luedeke on Tue Sep 13 11:54:16 2011
|
Some user wanted to modify the URL by hand and succeeded to crash the elogd process with npp=now
It appears that npp=0 crashes elogd with the following error message:
Program received signal SIGFPE, Arithmetic exception.
0x0808eba2 in show_elog_list (lbs=0xab3c770, past_n=0, last_n=0, page_n=1,
default_page=1, info=0x0) at src/elogd.c:20214
20214 sprintf(str + strlen(str), loc("Page %d of %d"), page_n, (n_msg - 1) / n_page + 1);
I guess this bug is not OS dependent: you can crash every logbook that you can search ;-) |
Re: Elog crashes with URL find npp=0, posted by Andreas Luedeke on Tue Sep 13 13:38:19 2011
|
> [...] It appears that npp=0 crashes elogd [...]
Here's a patch: search for "npp" in src/elogd.c and add the following line:
if (n_page<=0) n_page = 20;
Here's the diff output for version 2.9.0-2414
*** 20092,20096 ****
if (isparam("npp"))
n_page = atoi(getparam("npp"));
+ if (n_page<=0) n_page = 20;
if (page_mid) { |
elogd crash for special query, posted by Andreas Luedeke on Thu Oct 27 11:29:08 2011
|
A query to a logbook can crash the demon.
Query:
https://pc8059.psi.ch:444/SwissFEL+Injector/?jcmd=Find&m0a=10&d0a=27&y0a=2011&npp=1&reverse=0
gdb dump:
SSLServer listening on port 444 ...
Program received signal SIGSEGV, Segmentation fault.
show_elog_list (lbs=0xae72618, past_n=0, last_n=0, page_n=0, default_page=1, info=0x0) at src/elogd.c:20797
20797 message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id; |
|
ELOG deamon stuck in find_thread_head(), posted by soren poulsen on Sat Apr 30 19:45:30 2011
|
ELOG seems to enter a loop when you do certain opeations on certain messages: I moved a message to a different logbook and the deamon just gets stuck.
If I restart the daemon, the message was in fact moved: I can move it back to its original destination without problems.
I started in GDB and break with ctrl-C when the process gets stuck, to be told :
Program received signal SIGINT, Interrupt.
0x000000000040a968 in find_thread_head ()
I then made a core dump.
I put the files here: http://cern.ch/poulsen2/elog-error-report-110430.zip (they are too big to upload).
I get into the same problem in other circumstances such as when opening some threads (maybe because they contain "Reply-to" references to non-existing messages, but I have problems reproducing this on the test installation.
I should maybe also submit the incriminating thread.
Soren
|
|
Re: ELOG deamon stuck in find_thread_head(), posted by Soren Poulsen on Tue May 3 17:35:57 2011
|
| soren poulsen wrote: |
|
ELOG seems to enter a loop when you do certain opeations on certain messages: I moved a message to a different logbook and the deamon just gets stuck.
If I restart the daemon, the message was in fact moved: I can move it back to its original destination without problems.
I started in GDB and break with ctrl-C when the process gets stuck, to be told :
Program received signal SIGINT, Interrupt.
0x000000000040a968 in find_thread_head ()
I then made a core dump.
I put the files here: http://cern.ch/poulsen2/elog-error-report-110430.zip (they are too big to upload).
I get into the same problem in other circumstances such as when opening some threads (maybe because they contain "Reply-to" references to non-existing messages, but I have problems reproducing this on the test installation.
I should maybe also submit the incriminating thread.
Soren
|
1. It appears that some times find_thread_head is called with message references that do not exist. That is not good.
I put in a little check like this before seeing if the message has an "in_reply_to" reference:
The line:
if (lbs->el_index[i].in_reply_to)
becomes:
if (i < *lbs->n_el_index && lbs->el_index[i].in_reply_to)
2. The trouble started when I deleted a message in the middle of a thread, which left the thread badly "connected" (references to a deleted message).
3. Also, when a thread is badly connected, it is a problem moving messages to a different logbook. ELOG complains that it cannot access the message (with the invalid reference). But ELOG should ignore it, since the message was deleted.
Soren |