Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 275 of 807  Not logged in ELOG logo
ID Date Icon Author Author Email Category OSdown ELOG Version Subject
  67011   Mon Feb 7 15:14:36 2011 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.9.0-2384Re: Odd bug with conditional and required attributes

T. Ribbrock wrote:

I just ran into an odd bug with conditional attributes: If I add a certain attribute to "Required Attributes", none of the conditionals will work anymore. I have tried to create a small logbook definition that will demonstrate the problem (the original logbook is more complex and uses two sets of conditionals, both of which will be disabled when the bug hits):

; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config,Admin
List Menu commands = New, Select, Find, Logout, Help, Config, Admin, Import, Download
Date Format = %d/%m/%Y
List conditions = 1
List display = Edit, Type, Created, StatusA, StatusB, Archived, Test Text, Public?

; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
Required Attributes = Type

; Attribute Types
Type Created = date
Type Archived = date

; Options & Tooltips
Options Type = Type1{0}, Type2{1}
Options StatusA = Status-A-red, Status-A-orange, Status-A
Options StatusB = Status-B-red, Status-B-orange, Status-B
Options Public? = yes,no

; Conditionals
{0}Show Attributes Edit = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
{1}Show Attributes Edit = Type, Created, StatusA, Archived, Test Text, Public?

The above logbook definition works. However, if I replace the Required Attributes = Type with Required Attributes = Type, Public?, the conditionals will no longer work. I can see the difference in the reactions of the browser - with the extra attribute, nothing happens when I change "Type". Without, the browser will spring into action and reload as soon as I change "Type". I've tested this with both Firefox 3.6.13 and Konqueror 4.4.5 on Kubuntu 10.04 as clients. Fortunately, this is not a showstopper for me, as it is not mandatory to have this attribute defined as required, but I find it a weird issue nonetheless.

Cheerio,

Thomas

P.S.: I'm currently running the latest SVN version of elogd on OPenBSD as I ran into the same problem as described in Message 66984. The above problem also happens with the 2.8.1 I was using before. Some feedback: The SVN version compiled and ran without any further intervention on OpenBSD - very nice!

Your problem is the "?" in the attribute Public?.  Attributes may only contain ordinary characters. Unfortunately I did not document this so far. Therefore I put some fix in SVN revision 2387 which allows your attribute Public?, but I'm not 100% sure if this works in all places. The safest is just to remove the question mark.

  67013   Mon Feb 7 17:26:26 2011 Reply T. Ribbrockemgaron+elog@ribbrock.orgBug reportOther2.9.0-2384Re: Odd bug with conditional and required attributes

Stefan Ritt wrote:

 

Your problem is the "?" in the attribute Public?.  Attributes may only contain ordinary characters. Unfortunately I did not document this so far. Therefore I put some fix in SVN revision 2387 which allows your attribute Public?, but I'm not 100% sure if this works in all places. The safest is just to remove the question mark.

 Thanks Stefan, I'll try that. It's strange, though: At work, we're running 2.7.6 (and have used older versions in the past) and we have several logbooks with each at least one or two attributes with '?' and never had a problem with conditionals. Hence my surprise when this suddenly hit me with 2.8.1+ at home. Removing the '?' would be quite some work, as I'd have to change all logbooks and the associated data (the latter could probably be done with "rpl", I hope). I'll think about it.

  67102   Mon Aug 15 11:36:02 2011 Warning Kester Habermannkester.habermann@gmail.comBug reportOther2.9.0SEGV after upgrade from 2.7.8 to 2.9.0

Hello,

We've been using ELOG 2.6.5 to 2.7.8 for 4 years without any major problems.

Recently we upgraded to version 2.9.0 and since we've had the daemon frequently crash with SEGV.

I've detached debugging output from one time when ELOG the crashed. We've had many crashes
it was a different logbook each time. Platform is Solaris 10 5/08 on SPARC.

Has anyone else experienced problems with 2.9.0?

 

Best Regards

Kester

 

 

 

Attachment 1: elog-2.9.0-dbx.txt
signal SEGV (no mapping at the fault address) in show_elog_list at line 19781 in file "elogd.c"
19781         message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;
(dbx)
(dbx) list
19781         message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;
19782
19783         if (filtering) {
19784            status = el_retrieve(msg_list[index].lbs, message_id, date, attr_list, attrib, lbs->n_attr, text,
19785                                 &size, in_reply_to, reply_to, attachment, encoding, locked_by);
19786            if (status != EL_SUCCESS)
19787               break;
19788
19789            /* apply filter for attributes */
19790            for (i = 0; i < lbs->n_attr; i++) {
(dbx) print index
index = 0
(dbx) where
=>[1] show_elog_list(lbs = 0x1180200, past_n = 0, last_n = 0, page_n = 0, default_page = 1, info = (nil)), line 19781 in "elogd.c"
  [2] interprete(lbook = 0xffbd89f8 "Galileo-Coord", path = 0xffbd8648 ""), line 27213 in "elogd.c"
  [3] decode_get(logbook = 0xffbd89f8 "Galileo-Coord", string = 0xffbfe896 ""), line 27253 in "elogd.c"
  [4] process_http_request(request = 0x13a4eb8 "GET /Galileo-Coord/", i_conn = 1), line 28001 in "elogd.c"
  [5] server_loop(), line 28926 in "elogd.c"
  [6] main(argc = 5, argv = 0xffbffb8c), line 29947 in "elogd.c"
(dbx) print n_msg
n_msg = 49
(dbx) print *msg_list
*msg_list = {
    lbs         = 0x1195dd0
    index       = 1667786092
    string      = "\001\017��-D"
    number      = 0
    in_reply_to = 0
}
(dbx) print msg_list[index].lbs->el_index[msg_list[index].index].message_id
dbx: cannot access address 0x18da195b00  
(dbx) print ms(dbx) [index].lbs->el_index[msg_list[index].index].message_id
(dbx) print msg_list[index].lbs
msg_list[index].lbs = 0x1195dd0
(dbx) print msg_list[index].lbs->el_index
msg_list[index].lbs->el_index = (nil)
(dbx) pr(dbx) g_list[index].lbs->el_index
(dbx) print *msg_list[index].lbs
*msg_list[index].lbs = {
    name         = ""
    name_enc     = ""
    data_dir     = ""
    top_group    = ""
    el_index     = (nil)
    n_el_index   = (nil)
    n_attr       = 0
    pwd_xml_tree = (nil)
}
(dbx) print msg_list[1].lbs
msg_list[1].lbs = (nil)
(dbx) print msg_list[2].lbs
msg_list[2].lbs = (nil)
(dbx) print msg_list[3].lbs
msg_list[3].lbs = (nil)
(dbx) exit
  67121   Fri Sep 9 12:54:13 2011 Entry Stefan Rittstefan.ritt@psi.chInfoOther2.9.0Expiration of ELOG forum accounts

Dear ELOG users,

the ELOG discussion forum at PSI contains in meantime many old accounts with non-functional email addresses. Since this causes some overhead, it has been decided to clean up the current account database. In order to keep your account alive, please log in at the above forum before Friday, Sept. 30th, 2011.  If you fail to log in until that date, your account will be automatically deleted. Note that it will be always possible to re-create your account afterwards by simply clicking on "Register as new user", but before that you won't get automatic email notifications any more once your account has be deleted.

Sorry for the inconvenience, but the database contains currently too many wrong email addresses causing some flooding of our mail systems.

Best regards,

     Stefan Ritt

  67917   Wed May 20 01:52:23 2015 Entry Konstantin Olchanskiolchansk@triumf.caBug reportOtherthis onethis elog errors sending email
this elog gives errors sending mail through PSI email server. (did not capture the error messages, sorry). K.O.
  67918   Wed May 20 01:54:55 2015 Entry Konstantin Olchanskiolchansk@triumf.caBug reportOtherthis oneedit somebody else's draft
this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
  67926   Wed May 20 22:12:49 2015 Reply David PilgramDavid.Pilgram@epost.org.ukBug reportOtherthis oneRe: edit somebody else's draft
> this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
> methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
I find it odd that I can see someone elses draft, but never one that I am in the middle of composing (using a
different tab of the browser) in the elog listing.  There's one such draft Konstantin refers to in the logbook
listings now - last one was dark blue, this one a pink background, is there a reason for these different colours?
  67930   Fri May 22 13:50:31 2015 Reply Stefan Rittstefan.ritt@psi.chBug reportOtherthis oneRe: edit somebody else's draft
> > this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
> > methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
> I find it odd that I can see someone elses draft, but never one that I am in the middle of composing (using a
> different tab of the browser) in the elog listing.  There's one such draft Konstantin refers to in the logbook
> listings now - last one was dark blue, this one a pink background, is there a reason for these different colours?

I just tried that on the "Demo" logbook and could see my own draft entry (which appears pink) in a second tab.

Dark blue means you have not updated the default.css file properly from the current distribution.

Stefan
ELOG V3.1.5-3fb85fa6