Hi Stefan,

I have a thread of 70 entries.  I added another entry, which was saved, but elog crashed.
It would restart, but crash every time I then tried to access that 71 entry thread.

By editing the yymmdda.log files to remove the latest entry, all was well again.
Add a test new entry (much smaller) also crashed elog as before.

If it is any help, this is the error message I caught on a console:

src/elogd.c:703: xrealloc: Assertion `*((unsigned int *) (temp + old_size)) == 0xdeadc0de' failed.
./log: line 1:  3123 Aborted    

Now I have got around this, by ending that thread with reference to a new one to continue, but is this to be
expected?  

If this is something (like memory allocation) that would have been in hiding from the start, I cannot imagine
that it is likely to be hit often enough to actually "bug fix" - it might, in any case, cause problems elsewhere.

Hi Stefan,

I must have seen this before, but only just "noticed" it.

If you attach a picture or pdf to the first entry in a tread, there is then a paperclip after the thread display
line.  This shows up in threaded view or collapsed threaded view.

If you then attach a picture or pdf to a subsequent entry, the paperclip icon does not show up in threaded
display, (it is still there on the initial entry) but if the attachment is to the latest entry it shows up in
treaded collapsed display (collapse on last=1, of course).  If collapse on last=0, then initial entry shows on
threaded, collapsed, and that has the icon as expected.

When the icon does show, you can click on it and get the correct attachment to show/launch reader or whatever.

It would appear to be a bug that the attachment icon does not appear in the threaded display (for any entry
other than the initial one).

(sorry about the first posting, hit the wrong key sequence in error)

Regards,

David Pilgram.

I may have made this sound as if the issue occurs if the first entry in a thread has an attachment; in fact it
happens whether or not there is an attachment to the first entry.

Hope this makes matters a bit clearer.


> Hi Stefan,
> 
> I must have seen this before, but only just "noticed" it.
> 
> If you attach a picture or pdf to the first entry in a tread, there is then a paperclip after the thread display
> line.  This shows up in threaded view or collapsed threaded view.
> 
> If you then attach a picture or pdf to a subsequent entry, the paperclip icon does not show up in threaded
> display, (it is still there on the initial entry) but if the attachment is to the latest entry it shows up in
> treaded collapsed display (collapse on last=1, of course).  If collapse on last=0, then initial entry shows on
> threaded, collapsed, and that has the icon as expected.
> 
> When the icon does show, you can click on it and get the correct attachment to show/launch reader or whatever.
> 
> It would appear to be a bug that the attachment icon does not appear in the threaded display (for any entry
> other than the initial one).
> 
> (sorry about the first posting, hit the wrong key sequence in error)
> 
> Regards,
> 
> David Pilgram.

> It would appear to be a bug that the attachment icon does not appear in the threaded display (for any entry
> other than the initial one).

Yes, that's indeed a bug. I fixed it in SVN revision 2266.

Thanks Stefan!

(But I'll wait and see if you do anything about Steve's point...so I'll download "after work"!).

> > It would appear to be a bug that the attachment icon does not appear in the threaded display (for any entry
> > other than the initial one).
> 
> Yes, that's indeed a bug. I fixed it in SVN revision 2266.

(For some reason I could not add this in Dennis's thread.)

I like this new feature, BUT

I happen to have two Options:   Options System, and Options Status.

System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
this is made up)

Options System: 3.1, NT, 2000, XP, Vista

where the natural order here is chronological.

Perhaps the configuration file option could be more specific, for example

Sort attribute Options Status = 1

which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
the original syntax which defaults to sort *all* Options.

I've just noticed that it has also sorted another Option, which are selected as radio buttons.  Again, this is a
list which has a natural - again, in this case, chronological - order.

Because of this, I'm going to have to turn off this feature as it is on my system.  I hope something can be sorted
on this.


> (For some reason I could not add this in Dennis's thread.)
> 
> I like this new feature, BUT
> 
> I happen to have two Options:   Options System, and Options Status.
> 
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
> 
> Options System: 3.1, NT, 2000, XP, Vista
> 
> where the natural order here is chronological.
> 
> Perhaps the configuration file option could be more specific, for example
> 
> Sort attribute Options Status = 1
> 
> which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options.

Ok, that makes sense, so I changed it to

Sort Attribute Options Status = 1

as you suggested.

> (For some reason I could not add this in Dennis's thread.)
> 
> I like this new feature, BUT
> 
> I happen to have two Options:   Options System, and Options Status.
> 
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
> 
> Options System: 3.1, NT, 2000, XP, Vista
> 
> where the natural order here is chronological.
> 
> Perhaps the configuration file option could be more specific, for example
> 
> Sort attribute Options Status = 1
> 
> which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options.