[Monetdb-developers] Not descriptive error message

Robin Aly r.aly at ewi.utwente.nl
Fri Nov 17 16:39:13 CET 2006


Hi Fabian,

>> I recently compiled MonetDB on a NFS-home-directory (stupid, now
>> that I think of it). The error message I got was:
>> !FATAL: GDKlockHome: Database lock '.gdk_lock' denied
>>
>> After some investigations I found out that in
>> /cvsroot/monetdb/MonetDB/src/gdk/gdk_posix.mx
>> the original OS-error message was discarded and a simple error-return-value
>> was choosen. I suggest to change it to something like what is attached
>> to this mail.
>>     
>
> What was the actual problem in your case?  lockd not running?
>   
The problem was that the dbfarm directory resided on a NFS-directory
which didn't support locking (I don't know anything more specific, as I
don't maintain the server) But there is a process lockd running.
>   
>> Index: gdk_posix.mx
>> ===================================================================
>> RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_posix.mx,v
>> retrieving revision 1.119
>> diff -r1.119 gdk_posix.mx
>> 1765c1765,1766
>> < 	if (fd < 0)
>> ---
>>     
>>> 	if (fd < 0) {
>>> 		perror("MonetDB (open): ");
>>>       
>> 1767,1768c1768,1782
>> < 	if (lseek(fd, off, SEEK_SET) == off)
>> < 		ret = (lockf(fd, mode, len) == 0) ? 1 : -1;
>> ---
>>     
>>> 	}
>>>       
>
> With this change you actually change the behaviour of the function (and
> it's contract).  These kind of diffs are extremely hard to read, so I
> might be wrong.
>   
I am pretty sure that I didn't change the semantic of the function.
Except that
it outputted something stderr of course.
> In any case, perror is not the solution here, and as far as I know the
> current behaviour is used consistently within MonetDB at the moment.  It
> probably is better to try and fix this better at the caller of this
> function using errno and strerror.
>   
Ups, sorry, I didn't mean this "hack" to be meant a proper solution it
only served
as a trace to the problem. Maybe a stack of (errorno,strerror) would be
good - because
the error-handling function could also be calling this function indirectly.

Cheers
Robin

-- 
Robin Aly (PhD student, University Twente)
Phone: +31 (53) 489 4520
Fax:   +31 (53) 489 2927
email: r.aly at ewi.utwente.nl





More information about the developers-list mailing list