Seems a stack problem.  I don't have an OS X box to validate my guess.  I've
made a Google search with the keywords: EXC_BAD_ACCESS stack "os x"

Perhaps the following reply [1] might help...

  How big are they? You're probably running into the default stack size 
  limit, which is 512 KB. Try `unlimit stacksize` in your shell before 
  running, which will give you 65536 KB per stack.

[1] http://zerowing.idsoftware.com/archives/gtkrad-macos/2003-January/000453.html

Sridhar & Recai,

Thanks to both of you for the rapid and effective advice.  Fixing the limit corrected my problem.  
I think I last got tripped up this way 10 years ago...

I suppose that the advice to increase Mac OS X's default stacksize limit might make a fine entry 
in the FAQ or README file.

Thanks again,
Joe 

> I suppose that the advice to increase Mac OS X's default stacksize limit
> might make a fine entry in the FAQ or README file.

I added a note in the installation instructions. 
(http://midas.psi.ch/elog/adminguide.html)

- Stefan

Boolean attributes were not displayed correctly in version 2.3.9.
Patch is attached.

The width of the textarea after pressing reply is too large. 
The problem is that the algorithm that searches for the longes line
looks for the next '\r' which it does not find and therefore takes the
number of characters in the text to be the width of the longest line.
To search for '\n' instead should solve the problem.  Please find the 
diff output below.


$ diff -c elogd.c elogd.c~
*** elogd.c     Mon Aug  4 13:57:35 2003
--- elogd.c~    Fri Aug  1 13:13:09 2003
***************
*** 6028,6035 ****
      p = text;
      do
        {
!       /*      pend = strchr(p, '\r'); */
!       pend = strchr(p, '\n');
        if (pend == NULL)
          pend = p+strlen(p);
  
--- 6028,6034 ----
      p = text;
      do
        {
!       pend = strchr(p, '\r');
        if (pend == NULL)
          pend = p+strlen(p);
  

> The width of the textarea after pressing reply is too large. 
> The problem is that the algorithm that searches for the longes line
> looks for the next '\r' which it does not find and therefore takes the
> number of characters in the text to be the width of the longest line.
> To search for '\n' instead should solve the problem.  Please find the 
> diff output below.

Ok, implemented, thanks.

> Boolean attributes were not displayed correctly in version 2.3.9.
> Patch is attached.

Yes, implemented, thank you.

This is not really a bug, but elogd was getting really slow with our
logbook.  It took about 4 1/2 seconds just to get the default page in
threaded mode with 15 entries.  The logbook has in total about 2000
entries, though.

After playing around with the compiler option '-gp' and gprof the
problem was found: loc() is called about 18000 times per logbook
access!  (Attached you can find the gprof output.  There might be
other places where to save time: e.g. getcfg().)  The function loc()
calls stat every time to check if the language file was updated and
this takes a long time especially over NFS.

The quick solution for me was to just replace loc() with 'char
*loc(char *orig) {return orig;}'.  Therefore, I cannot use the
localization that I used anymore, which is not a big problem at the
moment.  After that the time to download the default page was only
0.16 s; almost a factor of 30 faster!

I would suggest to only read the language file (AND also the config
file!) once upon startup.  After changing things one has to restart
elogd, which is not so nice, but the long delay is not acceptable.
Another option not to restart elogd is to make elogd respond to a
signal (e.g. kill -HUP) to reread the config and language files.