ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66199
|
Sat Feb 7 01:59:53 2009 |
| Devin Bougie | dab66@lepp.cornell.edu | Request | Linux | 2.7.5 | Re: frequent crashes on SL4 | Hi Stefan,
I hope I'm not bombarding you, but we seem to be seeing crashes in two separate scenarios. In addition to the crashes I previously reported (editing a problematic entry and sending notifications), we
have a (seemingly) separate means of crashing elogd.
One of our users connects from home using a satellite network (bursty and high latency). Any time he attempts to upload an image from this connection, elogd crashes. He has not yet seen any
problems when using the same computer on site. Here are the stack traces I've obtained, first on SL4, then on SL5. Again, please let me know if there is any other information I can provide.
Thank you very much for your time and effort.
Sincerely,
Devin
------
[root@lnx100 ~]# gdb /usr/local/sbin/elogd 3728
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 3728
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.
0x080af727 in decode_post ()
(gdb) where
#0 0x080af727 in decode_post ()
#1 0x00000000 in ?? ()
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/local/sbin/elogd, process 3728
----
[root@lnx767 ~]# gdb /usr/local/sbin/elogd 13111
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 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/libthread_db.so.1".
Attaching to program: /usr/local/sbin/elogd, process 13111
Reading symbols from /lib/libssl.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libssl.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/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.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.6
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 /usr/lib/libkrb5support.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libkrb5support.so.0
Reading symbols from /lib/libkeyutils.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libkeyutils.so.1
Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libselinux.so.1
Reading symbols from /lib/libsepol.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libsepol.so.1
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
(no debugging symbols found)
0x00308402 in __kernel_vsyscall ()
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x080b2f8a in decode_post ()
(gdb) where
#0 0x080b2f8a in decode_post ()
#1 0x00000100 in ?? ()
#2 0x00000000 in ?? () |
66200
|
Sat Feb 7 06:26:48 2009 |
| Devin Bougie | dab66@lepp.cornell.edu | Request | Linux | 2.7.5 | Re: frequent crashes on SL4 | 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 ?? () |
Attachment 1: 090206a.log
|
$@MID@$: 570
Date: Fri, 06 Feb 2009 17:01:25 -0500
Author: Devin Bougie
Area: EXAMPLE
Type: EXAMP
Category: Beam Operation
Subject: beam running
Email: dab66@cornell.edu
Text: test
Record date: 1233939600
Attachment:
Encoding: plain
========================================
test
ka
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaagggg
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaafrfff
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhh
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaajjjjjjjj
aaaaaaaaaaaaa aaaaaaaaaaaaaffffffff
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaam
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
66206
|
Thu Feb 12 17:13:05 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Linux | 2.7.5 | Re: frequent crashes on SL4 | 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 |
66208
|
Fri Feb 13 16:57:02 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Linux | 2.7.5 | Re: frequent crashes on SL4 | 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. |
66267
|
Tue Mar 24 15:14:28 2009 |
| Devin Bougie | dab66@lepp.cornell.edu | Request | Linux | 2.7.5 | Re: frequent crashes on SL4 | Indeed, uploading images over a satellite connection does not crash the development ELOG server available from SVN. Our user was unable to
crash
elogd (or upload an image) and reports "The upload window would complain about an "upstream server", but the site was still there."
Thank you very much for your time and help (with both of the issues reported in this thread).
Sincerely,
Devin |
342
|
Fri May 16 08:34:44 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | | | Re: forum.css | > In the Config Examples logbook you mentioned a forum.css. Do you have a
> link to that css and others?
Sure, that's what the "Config Examples" logbook is for. Just click on the
tab on top of this page. The forum you will find
under elog:Config%20Examples/4 . |
2257
|
Wed Jun 27 15:06:24 2007 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | 2.6.5-1855 | Re: formating bug : css and Format command |
toumbi wrote: | Why Gain and G1,G2 .... G8 are on the same line ? |
Because you specified it! The first "1" in your format forces the attributes to show up on the same line. Just read the manual.
toumbi wrote: |
When I create a new entry, attibute 'attribgainname' is not used.( i can see lime color only when i see logged
message.) |
The 'attribmainname' is only used for the display page, not for the entry form. |
2258
|
Wed Jun 27 16:02:49 2007 |
| toumbi | toumbi@yopmail.com | Bug report | Windows | 2.6.5-1855 | Re: formating bug : css and Format command |
Stefan Ritt wrote: |
Because you specified it! The first "1" in your format forces the attributes to show up on the same line. Just read the manual.
|
Oups ... I understand better now how to put a new line .
this is my example.
; start a new line G1,G2...G8 Format G1 = 0,attribgainname,attribvalue,10,10
Format G2 = 1,attribgainname,attribvalue,10,10
Format G3 = 1,attribgainname,attribvalue,10,10
Format G4 = 1,attribgainname,attribvalue,10,10
Format G5 = 1,attribgainname,attribvalue,10,10
Format G6 = 1,attribgainname,attribvalue,10,10
Format G7 = 1,attribgainname,attribvalue,10,10
Format G8 = 1,attribgainname,attribvalue,10,10; start a new line I1,I2...I8 Format I1 = 0,attribgainname,attribvalue,10,10
Format I2 = 1,attribgainname,attribvalue,10,10
Format I3 = 1,attribgainname,attribvalue,10,10
Format I4 = 1,attribgainname,attribvalue,10,10
Format I5 = 1,attribgainname,attribvalue,10,10
Format I6 = 1,attribgainname,attribvalue,10,10
Format I7 = 1,attribgainname,attribvalue,10,10
Format I8 = 1,attribgainname,attribvalue,10,10
Stefan Ritt wrote: |
The 'attribmainname' is only used for the display page, not for the entry form. |
ok so if you say it is not a bug i can understand but in that case the format command work half in the entry form.
Is it possible to implement it for the next time?
thanks |
|