Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 49 of 807  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
    icon2.gif   Re: frequent crashes on SL4, posted by Devin Bougie on Sat Feb 7 06:26:48 2009 090206a.log
Hi Stefan,

Just incase it helps, I am attaching the file for an entry in our demo logbook.  If I edit this entry and click on submit (without checking "suppress email notification"), I get the seg fault shown below.

If I delete any single character from the entry, I do not see any problems.  If I re-insert a character anywhere, the problem returns.

I hope this is useful.  

Thanks again,
Devin

------
[root@lnx100 ~]# gdb /usr/local/sbin/elogd 6040
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /usr/local/sbin/elogd, process 6040
Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libz.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
0x008c17a2 in _dl_sysinfo_int80 ()
   from /lib/ld-linux.so.2
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x080ad900 in interprete ()
(gdb) where
#0  0x080ad900 in interprete ()
#1  0x00000031 in ?? ()
#2  0x000005dc in ?? ()
#3  0x00000000 in ?? ()
    icon2.gif   Re: frequent crashes on SL4, posted by Stefan Ritt on Thu Feb 12 17:13:05 2009 
Hi Devin,

first of all, your stack traces are only of limited use for me. This typically happens 
if you attach gdb to a running process, then you get something like

#0  0x080b2f8a in decode_post ()
#1  0x00000100 in ?? ()
#2  0x00000000 in ?? ()

(note the ??). If you run elogd directly from gdb, the stack trace contains much more information:

[meg@megon elog]# gdb elogd
...

(gdb) run
...
Server listening on port 8080 ...

Program received signal SIGINT, Interrupt.
0x0000003cb48c78d3 in __select_nocancel () from /lib64/libc.so.6
(gdb) where
#0  0x0000003cb48c78d3 in __select_nocancel () from /lib64/libc.so.6
#1  0x000000000046ea51 in server_loop () at src/elogd.c:27688
#2  0x0000000000471de8 in main (argc=1, argv=0x7fffe2b9bf18) at src/elogd.c:29018
(gdb) 

including the line numbers, arguments etc. So please try to start elogd from inside gdb 
and then reproduce your crash.

Your first problem seems to be related to some contents of your elogd.cfg, since in 
one stack dump I saw a 

strlen()
...
getcfg()

Here, the getcfg() function is called to retrieve some configuration from elogd.cfg. 
Maybe you have a very long line, or the file is otherwise corrupt. Please check that
carfully and send me your elogd.cfg so that I can have a look myself. Usually it helps
to remove one line after the other and check when the problem disappears.

Your other problem which has the decode_post() in the stack dump seems to be related
to the case when you upload an entry (or attachment), and the TCP link breaks in 
the middle. Probably the error handling in such a case is not correct. I will try
to reproduce this, although I don't have a satellite network.

Best regards,

  Stefan
    icon2.gif   Re: frequent crashes on SL4, posted by Stefan Ritt on Fri Feb 13 16:57:02 2009 
There was a general problem in submitting entries. If the TCP connection between the browser and elog 
disconnects during the transmission and only part of the request gets transferred, it consistently 
crashed elog. The probability for this is large if you have a slow connection and long attachments. The problem 
has been fixed in SVN revision 2174, so please upgrade and try again.
icon3.gif   Idea/Suggestion, posted by David Pilgram on Sat Feb 21 23:08:54 2009 
Hi Stefan,

In the past I have requested the "mark whole thread" feature, not yet implimented.  At present, I 
edit (in my case) the icon on the first entry to indicate current status of the thread.  I have 
had an idea connected to this.

If you view a page, in threaded form, and collapsed, the header of the first entry of each thread is 
shown.  The order, however, is that of the timed order of the latest entry in that thread.


As an option, under the same circumstances (threaded, collapsed), if the header of the most recent 
entry was shown, then that could also be an indicator of closed thread, or of "marking whole thread" 
option (maybe would be enough for those who desire those features).  It also gives an indication of 
the current status of the thread without having to edit the original entry of the thread to edit 
(for example) the icon. 

Just a thought on how to improve a wonderful program ;-)
icon6.gif   Text Limit for Subject line, posted by Robert Risher on Wed Feb 25 22:01:32 2009 

Is there any way I can limit the ammount of characters in the Subject line?

Thank you,

    icon2.gif   Re: Text Limit for Subject line, posted by Stefan Ritt on Thu Feb 26 10:01:37 2009 

 

Robert Risher wrote:

Is there any way I can limit the ammount of characters in the Subject line?

Thank you,

 

 Use the

Format Subject = ...

option as described in the manual. The last parameter is the "maximum number of characters allowed".

    icon2.gif   Re: Idea/Suggestion, posted by Stefan Ritt on Thu Feb 26 11:00:00 2009 
> In the past I have requested the "mark whole thread" feature, not yet implimented.

That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
add

Attributes = ..., Fixed
Options Fixed = boolean
Quick filter = Fixed

If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
Now if you want to mark the whole thread as fixed, do the following:

- go into list display
- display all entries in threaded mode
- click on "Select"
- select the thread you want to mark as fixed and click "Edit"
- now keep all attributes, but check the "Fixed" check box

and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
with one click.
    icon2.gif   Re: Idea/Suggestion, posted by David Pilgram on Mon Mar 2 22:00:33 2009 
Hi Stefan,

Must have missed it when the fixed/not fixed thread marking got implimented.

Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
(optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.



> > In the past I have requested the "mark whole thread" feature, not yet implimented.
> 
> That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
> add
> 
> Attributes = ..., Fixed
> Options Fixed = boolean
> Quick filter = Fixed
> 
> If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
> Now if you want to mark the whole thread as fixed, do the following:
> 
> - go into list display
> - display all entries in threaded mode
> - click on "Select"
> - select the thread you want to mark as fixed and click "Edit"
> - now keep all attributes, but check the "Fixed" check box
> 
> and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
> with one click.
ELOG V3.1.5-3fb85fa6