Bugs item #2607229, was opened at 2009-02-17 00:02
Message generated for change (Comment added) made by mr-meltdown
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2607229&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: MonetDB Common "stable"
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Stefan Manegold (stmane)
Assigned to: Martin Kersten (mlkersten)
Summary: testing does not report detected property errors
Initial Comment:
Since this checkin
===================================================================
2008/10/25 - mlkersten: MonetDB/src/gdk/gdk_bat.mx,1.204
Most of the changes are related to moving GDKwarning into proper
debugging statements.
The major change is in gdk_utils, where the failure to vtrim does not
lead to a system crash anymore. It is properly retained in the errbuf
for the upper layers to consume.
===================================================================
(cf.,
`cd .../MonetDB &&
cvs diff -r1.20{3,4} src/gdk/gdk_bat.mx`)
BATpropcheck no longer reports incorrect BAT properties as ('!'-prefixed)
GDKwarning, but rather as simple '#'-prefixed comments.
Since the latter are (for good reasons) ignored by testing (Mdiff), testing
does no longer report incorrect BAT properties as detected by BATpropcheck.
Consequently, property errors can silently sneak into tests unnoticed, and have
indeed done so, e.g., look for "BATprocheck:" at
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTests103/Int.64.64.d.1-Fedora8/src_test_bugs/rangejoin_optimize_bug.out.00.html
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTestsg103/GNU.64.64.d.1-Fedora8/tests_BugTracker/pf-O0_produces_wrong_MIL.SF-1771532.out.00.html
----------------------------------------------------------------------
>Comment By: Fabian (mr-meltdown)
Date: 2009-08-01 10:16
Message:
lines starting with # are warnings and stored by clients in the warning
stack
lines starting with ! are errors and may not be followed by other content
(e.g. an error is fatal)
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-08-01 09:49
Message:
Propcheck error reporting was/is a mess.
They appear both as
GDKerror("BATpropcheck: BAT %s(....
GDKfatal("BATpropcheck: BAT %s(%d) ...
XPROPDEBUG THRprintf(GDKout,"#BATpropcheck: BAT %s
THRprintf(GDKout, "#BATpropcheck: BAT ....
I would like to know what is the real semantics.
Mixing debugging information with real error reporting
is/was not a good design.
All debugging statements are marked by # which
should be ignored in non-raw mode of the front-ends.
All errors should be marked ! and handled within the
context of their respective interpreters properly.
If the consensus is that propchecks are errors, then
they should all go through GDKerror.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-08-01 09:44
Message:
Ok, the last three (lines 3385, 3387, 3390 in revision 1.221 of
MonetDB/src/gdk/gdk_bat.mx) are fine as mrerely informative debug
messages.
But the others (lines 3282, 3369, 3374, 3376, 3379, 3381 in revision 1.221
of MonetDB/src/gdk/gdk_bat.mx) indicate real error and should IMHO hence be
reported/treated as such (again).
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-08-01 09:38
Message:
$ grep --color -n 'GDKerror.*BATpropcheck:' MonetDB/src/gdk/gdk_bat.mx
2985: GDKerror("BATpropcheck: BAT %s(%d) set inconsistent
hseqbase: "
OIDFMT " != " OIDFMT " => " OIDFMT "\n", BATgetId(b), b->batCacheid,
b->hseqbase, bm->tseqbase, o);
3014: GDKerror("BATpropcheck: BAT %s(%d) has inconsistent
accrefs\n",
BATgetId(b), b->batCacheid);
3019: GDKerror("BATpropcheck: BAT %s(%d) recovered hkey\n",
BATgetId(b),
b->batCacheid);
3023: GDKerror("BATpropcheck: BAT %s(%d)[%s,%s] with "BUNFMT"
tuples is
dense but not key!?\n", BATgetId(b), b->batCacheid, ATOMname(b->htype),
ATOMname(b->ttype), BATcount(b));
3035: GDKerror("BATpropcheck: BAT %s(%d) with "BUNFMT" tuples seqbase
of
dense oid bat is wrong! " OIDFMT " != " OIDFMT "\n",
BUT:
$ grep --color -n 'THRprintf.*BATpropcheck:' MonetDB/src/gdk/gdk_bat.mx |
grep -v 'DEBUG THRprintf'
3282: THRprintf(GDKout, "#BATpropcheck: BAT
%s(%d): could not allocate
hash table for key test\n", BATgetId(b), b->batCacheid);
3369: THRprintf(GDKout,"#BATpropcheck: BAT %s(%d)[%s,%s] with
"BUNFMT"
tuples was incorrectly marked sorted!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
3371: THRprintf(GDKout,"#BATpropcheck: BAT
%s(%d)[%s,%s] with "BUNFMT"
tuples remains marked radix-clustered on %d bits; not checked!\n",
BATgetId(b), b->batCacheid, ATOMname(b->htype), ATOMname(b->ttype),
BATcount(b), BAThordered(b) >> 1);
3374: THRprintf(GDKout,"#BATpropcheck: BAT %s(%d)[%s,%s] with
"BUNFMT"
tuples was incorrectly marked keyed!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
3376: THRprintf(GDKout,"#BATpropcheck: BAT %s(%d)[%s,%s] with
"BUNFMT"
tuples was incorrectly marked nonil!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
3379: THRprintf(GDKout,"#BATpropcheck: BAT
%s(%d)[%s,%s] with "BUNFMT"
tuples was incorrectly marked dense!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
3381: THRprintf(GDKout,"#BATpropcheck: BAT
%s(%d)[%s,%s] with "BUNFMT"
tuples had incorrect seqbase!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
3385: THRprintf(GDKout,"#BATpropcheck: BAT
%s(%d)[%s,%s] with "BUNFMT"
tuples was not marked sorted!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
3387: THRprintf(GDKout,"#BATpropcheck: BAT
%s(%d)[%s,%s] with "BUNFMT"
tuples was not marked keyed!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
3390: THRprintf(GDKout,"#BATpropcheck: BAT
%s(%d)[%s,%s] with "BUNFMT"
tuples was not marked dense!\n", BATgetId(b), b->batCacheid,
ATOMname(b->htype), ATOMname(b->ttype), BATcount(b));
This report (see initial comment) refers to the latter.
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-08-01 08:59
Message:
The current source turns all messages into a GDKerror, which is handled
like any other error. In particular it means that it is converted into a
MALexception. If there is a case where this is not properly done, or not
shown properly on the prevalent output stream, we have to investigate it.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-08-01 06:39
Message:
What was the actual reason to turn crucial property errors/warning into
"harmless" purely informative debug messages?
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-07-31 22:59
Message:
So, if the Mtest recognizes them and reports them, then this bugreport can
be closed.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-07-31 22:15
Message:
Mtest.py / Mfilter.py now recognize BATpropcheck messages in any case and
treats them as error.
IMHO, incorrectly set properties are errors, and should hence also be
reported as such, in case they are detected, i.e., when property checking
is explicitly enabled (e.g., during testing and debugging) ...
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2009-07-31 21:39
Message:
Would it be a solution to mark them as #!, which means that the test
analysis scripts look a little further.
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-02-22 09:57
Message:
see also
[ 2627138 ] SQL: test fails with BATpropcheck error
https://sourceforge.net/tracker/index.php?func=detail&aid=2627138&group_id=56967&atid=482468
and
[ 2627137 ] PF: tests fail with BATpropcheck error
https://sourceforge.net/tracker/index.php?func=detail&aid=2627137&group_id=56967&atid=482468
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-02-21 20:12
Message:
Since correct handling of properties is not that unimportant for MonetDB, I
made testing treat property inconsistencies as reported by BATpropcheck as
errors, again, regardless of whether BATpropcheck reports them as errors or
as comments.
Details to be seen as of tomorrows' testing results.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2607229&group_id=56967
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
