ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
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. |
66219
|
Sat Feb 21 23:08:54 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | Linux | 2.7.5-2130 | Idea/Suggestion | 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 ;-) |
66222
|
Wed Feb 25 22:01:32 2009 |
| Robert Risher | robert@gmail.com | Request | Windows | V2.7.5-217 | Text Limit for Subject line | Is there any way I can limit the ammount of characters in the Subject line?
Thank you, |
66224
|
Thu Feb 26 10:01:37 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Windows | V2.7.5-217 | Re: Text Limit for Subject line |
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". |
66225
|
Thu Feb 26 11:00:00 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Linux | 2.7.5-2130 | Re: Idea/Suggestion | > 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. |
66231
|
Mon Mar 2 22:00:33 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | Linux | 2.7.5-2130 | Re: Idea/Suggestion | 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. |
|