Hi,

elogd sometimes crashes when there are large cookies. Or I'd guess it has something to do with the cookies, elogd crashed over and over again until I cleaned out cookies and authenticated sessions in firefox, then it stopped.

When I run "elogd -v" in gdb, and someone does:

GET / HTTP/1.1
Host: bba.eld.ki.sw.home.se:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; sv-SE; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: urem=0; TWIKISID=ecaa5a39e8446a27ec5a34bcbb9d4bcb; unm=erirone; upwd=c3w5MTg1; ipplanNoAuth=yes; SMSESSION=oKvAAv/J9WoCo6KoVdEJkhxz44G10x7TXigffOaAjLrSf0iOFrRJq97oWl32/UBQMvFslc4BgxN/VCz2K7/IRaKdFgmU4CHq/1UUv2RvdHB2HUbYbph+JgKUpAG+kN6Cc4BTwRWhmemUNhONXMRJUCfa6Tq9/osID2AT1wBFInFNww2xVmJPDSi1oltxtT345RgdGQIZbHzG2HBi1GijpiaD+4FI3WLLRzJOj3Art92BLlVDWSaPxKSdSZgVNfRSw33SupUqwD0Is2pc+ufKn4cg0azyOTLNDFOl0U5RI7K9AVgYM0NBsfDoEyBfK8pYIZTMqFFQsnWAdwYz9M2RLDBKyfMXdfGb3rrnOdPH0zvvkkoT01pZObI7dSqHD7IXLbjN/8Pt0O4eo5/SSQ7uKRGpBip0pKe3mxZYI4hsJejYwVBFegovS4qSUiL8UGDhG+lB20WEmDwIQfTG2ZtpckLC6t1CNfa5eFLWCOm+yESU+3AmP4zdJLJSqbznEl2SQTePP5NzI1R5WTAvBbsgX+N9Ab1g0Yui/i042qWNQPLg3/5c/WCHqzImi45+ov42C4mj9OcjGcAf7kaWBMwfdwfChREWkSpMrC2RRndlw+iVbShSK7lVfoCvIqk4491uQBT3bz3S0e56Vin+Oj8qbmEA/5Hp1x9b80qTRy/8lj7KLgbhV60BBvX7ahOkrIFCSjTi8y87K/u4b3KQHesNZgA7SyWRuT+vY4XCb8ANVl8eIui7vK5NNSiFFqLZ1IoeFaVu+gS/hhDu3m/rmK2t5iR2YW/aKmnGTVQsPPy/POVY/zXWgf7c6ps/sSMwTk9sy5Yr8yGYBSUrtZkn1/gK0wpqlRCcjuG991sfgr/UKbhK1dU0rI9E9PBPhvLQpjUHT49AAHL9A9S3FOs66CAFsoVo00WNqKuZcmLpEgXdpbW+mj43tiNugCT98Ec8+Iq0rZYKhYdqFu9AUOdJVXk2udBx9VkOVcRYteFICtwz3fvR02KCU3Sn3a0HKZ4wWOujUnH4nThZGVlUNyg/Of+9GKXY4mxqv/5ocEkO4q8xmAP/OJHrvgJ42kTAjaVgjlSG3b5iJTcu4jvqfC/yKU88Sw==


*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated
 

*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7dad875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7daf201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7de4e5c in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0x00000000 in ?? ()
(gdb)

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.

I have a really odd issue with elog...

My setup:

elogd.cfg:
[global]
port = 2109
SMTP host = localhost
Resource dir = /usr/share/elog
Logbook dir = /srv/www/elog
charset = UTF-8
Main Tab = main
URL = https://elog.codemages.net
Relative redirection = 1
Usr = www
Grp = www
Resolve host names = 0
Self register = 0 
Admin user = ruskie
SSL = 0
Login expiration = 20

[links]
Subdir = links
Theme = default
Comment = Link spam
Attributes = Author, Category, Link, Comment
Options Category = General, Law, IT, Odds, Linux
Required Attributes = Link, Comment
Page Title = ELOG - Link spam
Reverse sort = 1
Quick filter = Date, Category
Time format = %Y-%m-%dT%H:%M
Date format = %Y-%m-%d
Password file = links.pwd
Admin user = ruskie
RSS Title = $logbook $entry time :$Author :$Link :$Comment

[notes]
Subdir = notes
Theme = default
Comment = Various notes
Attributes = Category, Comment
Options Category = General, Law, IT, Odds, Linux
Required Attributes = Comment
Page Title = ELOG - Various notes
Reverse sort = 1
Quick filter = Date, Category
Time format = %Y-%m-%dT%H:%M
Date format = %Y-%m-%d
Password file = notes.pwd
Admin user = ruskie
RSS Title = $logbook $entry time :$Comment


lighttpd.conf:
$HTTP["host"] =~ "elog.*" {
  proxy.server = ( "" =>
                   ( "10.0.0.10" =>
                     (
                       "host" => "10.0.0.10",
                       "port" => 2109
                     )
                   )
                 )

}

If I access elog directly on 2109 I get no issues but when I use this configuration it takes minutes to access
any elog page at all. But the odd thing is this only happens when I'm using a gecko based browser(firefox,
xulrunner based etc...) if I use webkit-gtk or elinks all the pages load up with no noticable delay.

I have tried this on different computers, different configurations and so on... And always the same behaviour
when it comes to a gecko based browser. Elinks and webkit-gtk load up fine.

Marking this as Other so far. If anyone knows anything about running elog and lighttpd togheter please speak up.

    for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )
        if (i < (int) sizeof(cookie)-1)
            cookie[i++] = *p++;

    for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n';)
        if (i < (int) sizeof(cookie) - 1)
            cookie[i++] = *p++;
        else
            break;

    for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; ++p)
        if (i < (int) sizeof(cookie)-1)
            cookie[i++] = *p;

Hi,

A user tried to import a CSV file, which caused e-log to add a field called "date" to the list of attributes (and then crash). This caused the log-book to be blocked until someone (guess who) would go edit the elogd.cfg file and then trigger a reload.

1. suggestion : E-log should not crash in this case

2. suggestion: E-log should not allow invalid attributes to be added via CSV Import, which causes the log-book to be blocked.

For the time being, I will just  "Deny import" (by the way, the doc says it is "Deny CSV import", but I think the syntax is "Deny import". Not really important.

I think this should be quite easy to reproduce.

Thanks a lot

Soren

With a logbook defined by 

 [test]
 Theme = default
 Comment = Test of auto-increment
 Attributes = Batch
 Subst Batch = %Y%m%d-##

the auto-incrementing of the Batch attribute within dates works when the logbook contains only entries for
today's date but otherwise will give a batch number of "01" for each entry.  

Changing line 8714 of elogd.c as follows, from:

      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         old_index = 0;   
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);
to
      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         break;            /* <------------- */
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);

appears to fix this bug when I test it.  This code is inside a loop stepping back through all log entries, and
the variable old_index is already set to zero before the loop. The existing code resets old_index whenever the
prefix of the attribute string (containing a date) does not match the "current" value of that prefix as found in
retstr (set using strftime).  So, if there are any records for dates other than today then old_index is reset
and attribute values will be set with the counter = (old_index+1) = 1.  The modified version stops comparisons
once a different date is seen, but assumes that records are date ordered.  An alternative patch:

      /* if date part matches */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
          /* retrieve old index */
         if (atoi(attrib[index] + loc) > old_index)
            old_index = atoi(attrib[index] + loc);
  
does not make this assumption and also appears to work OK when I test it.

When adding a log entry containing a datetime field using the IE7 browser a Javascript warning is displayed - see the attachment.  This is due to a change in the naming of the "seconds" field of a datetime entry (made in version 2143) not being propagated to the code that generates the Javascript that checks the supplied values.

Suggested patch follows.

Change "s%d" to "c%d" in lines 9675 and 9678.

Showing lines 9675-9680 below, change from:

               rsprintf("  if (document.form1.s%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.s%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

to:

               rsprintf("  if (document.form1.c%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.c%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

Regards,

Richard Stamper

For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.

I've been running elogd like this (to get more info)

elogd -v > elog-2233-2.log 2>&1

The last entry I get in the log when elogd crashes is:

  Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"

I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.

Any additional information you need: Just let me know.

Regards,

Thomas