This problem has been fixed in revision 2.7.5-2143. Please upgrade.

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)

 Stefan,

perhaps there should be something like the bold text below in elogd.c:

int process_http_request(const char *request, int i_conn)^M
...

   /* extract cookies */^M
   if ((p = strstr(request, "Cookie:")) != NULL) {^M
      p += 6;^M
      do {^M
         p++;^M
         while (*p && *p == ' ')^M
            p++;^M
         strlcpy(str, p, sizeof(str));^M
         for (i = 0; i < (int) strlen(str); i++)^M
            if (str[i] == '=' || str[i] == ';')^M
               break;^M
         if (str[i] == '=') {^M
            str[i] = 0;^M
            p += i + 1;^M
            for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' && i < (int) sizeof(cookie); i++)
                      cookie[i] = *p++;

...

[demo]
Attributes = Author, Type, Subject, Old/New
Options Old/New = Old, New
Quick filter = Type, Old/New

 Thanks for the advice!

I've just had time to set up a test for this using both empty and populated logbooks (which don't have Hardware/Software in every entry as the field was added recently) and newly created logbooks (which have consistent attributes) and saw the problem on . 

The control ("Hardware/Software") causing the problem has three options "Hardware Only", "Software Only" and "Both".  The problem happens every time you click on the "-- Hardware/Software --" (i.e. All) option in the Quick Filter after having previously selected one (or more) of the options as a filter.  This produces the error:

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
*   This problem can sometimes be caused by disabling or refusing to accept cookies.

I ran elog with a trace (attached) which shows lots of:

select(1024, [5], NULL, NULL, {1, 0})   = 1 (in [5], left {1, 0})
recv(5, "GET /Change_Log/?Hardware%2FSoftware=_all_ HTTP/1.1\r\nHost: localhost:8080\r\nUser-"..., 100000, 0) = 619
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
time(NULL)                              = 1227528904
send(5, "HTTP/1.1 302 Found\r\nServer: ELOG HTTP 2.7.5-2130\r\nConnection: Keep-Alive\r\nKeep-A"..., 199, 0) = 199
send(5, "<html>redir</html>\r\n", 20, 0) = 20

messages after selecting "-- Hardware/Software --"

The only difference between today's test and last week's is that today the browser is on the local machine.

I also attach my (anonymised) elogd.cfg

Hope this helps

regards

Steve

Thanks to your detailed description I could reproduce and fix the problem. Please download SVN revision #2144 and give it a try.

Wow, where did you get that long cookie from? Certainly not from elogd. You must run elogd under Apache, and have some other service next to it on your server which distributes this long cookies, that's why other people did not experience this problem yet. I appreciate your fix. It's alwasy nice to see users not only complain about things, but try to fix them. Your fix is almost correct, you need a

i<(int) sizeof(cookie)-1

since there is the trailing zero for terminating the cookie string. I applied your fix to SVN revision #2146.

We have an auto-incrementing reference attribute defined as:

# RFC

Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change

We also have a "Created by/when" attribute.  Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the  $@MID@$ seems to be set when the user clicks "Submit".

# Created

Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date

Every once in a while the incrementing stops working and the number 'sticks' or misses some out.  It looks as if it might be because multiple people are adding entries concurrently.  Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated?  Here is a list showing the discrepancies.

Date        Item     Time Stamp (from the line after $@MID@$)  "Created" attribute time stamp

22/09/08    124      16:15:10                                   11:58

22/09/08    125      16:33:54                                   16:24

22/09/08    125      16:35:37                                   16:33              Should be 126

...

10/10/08    146      10:39:09                                   10:30                    Correct

10/10/08    146      10:46:57                                   10:35              Should be 147

10/10/08    147      13:04:03                                   13:02              Should be 148

10/10/08    148      15:11:38                                   15:00              Should be 149

...

17/11/08    171      10:21                                      10:17              Correct

17/11/08    174      14:30                                      13:47              Should be 172

17/11/08    175      16:14                                      16:04              Should be 173

17/11/08    176      16:49                                      16:38              Should be 174

...

25/11/08    187      15:49:58                                   15:47              Correct

25/11/08    187      15:52:39                                   15:48              Should be 188

25/11/08    188      16:49:56                                   16:44              Should be 189

25/11/08    188      16:52:40                                   16:40              Should be 190

25/11/08    188      16:55:17                                   16:43              Should be 191

Let me know if you need any more information.

regards

Steve

Tested SVN v 2147 and all looks OK

thanks

Steve