Glenn A. Thompson wrote:
> Hey guys,
>
>>
>> Glenn Thompson posted a patch for this in issue 1358, but it never got
>> applied; it was a very complex. (cmpilato says we didn't apply the
>> patch because we were passing a baton as a const char * parameter, and
>> we wanted Sleepycat to change the api to void *, and we were going to
>> work around it by parsing/unparsing memory addresses to/from strings.
>> Gat's patch also opened us up to a generic logging mechanism within
>> libsvn_fs_base.)
>>
> Yes I marshaled a pointer. But I did it for good not evil:-) The
> problem was that the BDB docs weren't clear as whether that argument
> would be used in *their* logging. It *seemed* to say that it wouldn't
> be used when set_errcall functions were registered. To be safe, I had
> a compilation flag that controlled passing the pointer directly or
> would make it a string. When passed as a string it would not segfault
> if it were printed by BDB internal functions.
>
> As for the patch being complex, I don't recall it being that bad.
> Either way, IMHO a logging system is **LONG** overdue.
Yes!
> There was a log4j type thing called log4c that looked like it had
> potential.
Whatever we use (and I'm very much in favour of log4c or equivalent,
despite objections that it's "overengieered"), the fact that we cannot
produce _any_ kind of log -- neither activity log, nor debug trace (btw,
I also found http://ctrace.sourceforge.net/, which is suspiciously
similar to (although somewhat expanded from) my own tracing library).
And that is bad because it complicates server debugging.
Anyway, suspect that all the BDB problems stem from some kind of library
incompatibility...that we should be detecting at runtime, but somehow
aren't.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 28 23:31:46 2004