NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

lib/48314: libevent test failures are real



>Number:         48314
>Category:       lib
>Synopsis:       libevent test failures are real
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 16 07:25:00 +0000 2013
>Originator:     Martin Husemann
>Release:        NetBSD 6.1_STABLE (but the same effect is visible in -current)
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD night-porter.duskware.de 6.1_STABLE NetBSD 6.1_STABLE (PORTER) 
#6: Wed May 29 21:38:20 CEST 2013 
martin%night-porter.duskware.de@localhost:/usr/src-6/sys/arch/i386/compile/PORTER
 i386
Architecture: i386
Machine: i386
>Description:

A bit of background: I have a JavaScript/html5 application [which I 
unfortunately can not disclose here], that heavily relies on javasript timers
(lots of them) and is slightly critical in getting those fired at the
expected times. This web page works on anything, all browsers tested so far,
even mobile ones on pretty slow devices.

However, it consistently fails on Firefox on NetBSD.

If I read the firefox code correctly, it heavily relies on libevent and its
timeouts to organize its internal queue of future events and callbacks to
fire. This now leads to the main point of this PR:

In pkgsrc/devel/libevent an "make test" fails spectactularily. Basically all
timing related tests plain fail.

Compare to that our ATF tests for it and then see the difference:

src/external/bsd/libevent/dist/test/regress_thread.c has this log:
----------------------------
revision 1.4
date: 2013-04-12 22:00:21 +0200;  author: christos;  state: Exp;  lines: +5 -3;
branches:  1.4.4;
#if 0 more
----------------------------
revision 1.3
date: 2013-04-12 21:59:26 +0200;  author: christos;  state: Exp;  lines: +7 -3;
XXX: disable the simple conditions test right now because it depends on
thread scheduling timings and we don't seem to schedule threads the way
it assumes.
----------------------------

I think this XXX statement points to a real bug, either in libpthread or
the kernel.

>How-To-Repeat:
Run pkgsrc libevent tests.

>Fix:
no idea yet



Home | Main Index | Thread Index | Old Index