Hi

I am having a little problem with e-log that I can easily reproduce.

I have defined a number of constraints on my e-log fields and I am testing what happens when the user does not respect them.

So this only happens when I am not observing the input formats or the mandatory fields.

This is the GDB trace. This is not very verbose, so I must learn to use the other tracers, I guess.

Soren

It would be best if I could reproduce your problem. So can you start from a very simple configuration file, add your constraints until the problme happens, and then send me the config file? 

Hi

The problem is not exactly what I thought, but I did track it down. Here is a logbook definition that reliably creates a segmentation fault in e-log. This logbook's only useful purpose is in fact to create a segmentation fault:

You select "New", then "Select", without entering anything.

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

Login user = Admin

Attributes = Link

Change Link = <a href="https://$Link"">$Link</a>

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

I would be able to create some more debugging information of course, if needed.
 

Regards

Soren

> > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > This was observed on Solaris 10 (SPARC).
> > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> 
> I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe 
> you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to 
> start the daemon interactively and see what exactly happens if you send several SIGHUPs.

The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
is called.  Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.

The solution is to use the POSIX sigaction() call instead of signal(). 

> > > elogd continues to run after a SIGHUP. If a second SIGHUP is received the daemon terminates.
> > > This was observed on Solaris 10 (SPARC).
> > > The documentation states that elogd should re-read configuration after receiving SIGHUP.
> > 
> > I tried to reproduce this but without success. I could send many SIGHUPs without the daemon terminating. Maybe 
> > you modified the configuration file in between and elogd barked out because of some wrong configuration? Try to 
> > start the daemon interactively and see what exactly happens if you send several SIGHUPs.
> 
> The problem is that under Solaris signal handlers installed via signal() get uninstalled *before* the signal handler
> is called.  Thus the second time elogd receives a SIGHUP, you get the default action, which is to kill the process.
> 
> The solution is to use the POSIX sigaction() call instead of signal(). 

Can you try to modify the signal() calls into sigaction(). If this really works under Solaris, I will incorporate this 
then into the distribution.

I had finally the same problem. This is due to a bug indeed inside is_script(). It has been fixed in revision 2201. 

Thanks for reporting this bug. I fixed it in revision #2203. 

I fixed this in revision #2204. The attachment names now stay the same. There is one tiny risk of screwing up, namely if you have the same attachment name in two different logbooks (accidentally also submitted at the same second and therefore the same time stamp). If you then copy these two entries to a third logbook, one attachment will overwrite the other one, but that risk is indeed really small. I actually had to re-write the link to the attachment inside the text body (even differently for ELCode and HTML encoding). So I'm not 100% sure I covered all cases, so just give it a try.