I tried to reproduce your problem with following simple configuration file:

[Bergman]
Attributes = Author, Status
Options Status = open, closed
Preset Author = $long_name

The result was that it worked fine (see attachments). Maybe there is another setting in your configuration file which causes the problem. Can you try the simple configuration and see if it still crashes?

I'm now running eLog  2.9.0 and seeing the same crashes. However, I've got some more information that may be helpful.

The crash seems to be directly related to the order of replies in the thread. For example, in this thread I am replying to the original entry. The original entry has 2 children (the entries are siblings) and no grandchildren.

In our installation, eLog crashes consistently under the following conditions:

       go to the "list" display

       set it to "threaded"

       "select" a thread that has siblings at any generation of replies

       choose "edit"

If the selected thread only has one entry at any generation, eLog does not crash.

Here's a horrible attempt at a display of two message threads. Note that in the first example, there are 2 replies at the same generation (siblings)--both the person who responded and the original submitter replied to the initial submission. After that, all replies were to successive generations.

-------------- Causes eLog to Crash ------------------
!   Full Name (submitter) module failure 
    =>   Full Name (submitter) Re: module failure 
    =>   Full Name (replier) Re: module failure 
               =>   Full Name (submitter) Re: Re: module failure 
                         =>   Full Name (submitter) Re: Re: Re: module failue

------------------------------------------------------



-------------- No eLog Problem  ------------------
!   Full Name (submitter) Labwide failure of mcc 
    =>   Full Name (replier) Re: Labwide failure of mcc 
           =>   Full Name (submitter) Re: Re: Labwide failure of mcc 
                     =>   Full Name (replier) Re: Re: Re: Labwide failure of mcc 
------------------------------------------------------

 I am also experiencing the same exact problem as explained above. It only seems to happen when a part of the title has changed. I will include my config for an example. Make a few entries, then change the "Customer" paramater. Then try and edit an entry in the thread.

 Enable attachments = 1

Attributes = Employee, Customer, XXX-ID, XXXX Number, SCD, Type, Status, Folder Created, XXXX Received, Equipment Installed, XXX Carrier Up, Customer Carrier Up, QA Completed

Thread display = $Customer  -  $SLR-ID  -  $Type  -  $Status  -  SCD: $SCD  - XXXX: $XXXX Number

Propagate attributes = Status

Locked Attributes = Employee
Options Type = Activation, Termination, Change
Options Folder Created = Yes, No, N/A
Options XXXX Received = Yes, No, N/A
Options Equipment Installed = Yes, No, N/A
Options XXX Carrier Up = Yes, No, N/A
Options Customer Carrier Up = Yes, No, N/A
Options QA Completed = Yes, No

Entries per page = 100

Preset Text = $short_name @ $utcdate -
Append on reply = $short_name @ $utcdate -

Locked Attributes = Employee

Preset Employee = $long_name

Options Status = Open, Closed

Quick Filter = Status, Type

Type SCD = datetime

Summary lines = 0
Enable Attachments = 0
Suppress default = 2
Entries per page = 10

Suppress Email to users = 1

Display mode = threaded
Collapse to last = 1
Expand default = 0
Subst on reply Employee = $long_name 

Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x000646c7.

Oops! I 're-used' the '-s' flag for email suppression, so it was actually 
double used. I changed the email supprssion flag to '-p', so '-s' should 
work again for specifying subdirectories.

• A bug which has been fixed in meantime. If you can give a try to 2.6.2-1750 or so that could help. I'm not sure if this version is already in the Debian distribution since I'm not the maintainer there.
  
• A corrupted log file. If one of the YYMMDDa.log file get some garbage (maybe due to hard disk problems etc.) the elogd server can run into an infinite loop. In that case examine all log files to see if there is anything wrong. If so, edit it manually and restart elogd.
  
• Some not yet found bug. One never can exclude this of course, but at this forum I have elogd running under similar conditions like you, and it runs for months without problems.