trying to track down memo-file conduit bug

[Jason 'vanRijn' Kasper <vR movingparts net>]

so, I spent some time last night trying to track down the memo-file
conduit bug and I'm confused.

I've diffed the memo_file directory between 0.10 and 2.0.10 and there's
VERY little code that has changed between the two versions--certainly
nothing that looks fishy.

Also, I've added debug statements to track down where gpilotd is dying,
exactly, and I have narrowed it down to one line of code, and now I'm
even more confused.  The memo_file conduit seems like it doesn't have
any problems finishing its task.  The bug seems to be in gpilotd(?).... 

Specifically, when I do a regular synchronize between my palm and
gpilotd, with ONLY the memo_file conduit enabled, the last thing I see
gpilotd print out is this  "Performing Fast Synchronization", which is
at line 1598 or so of gnome-pilot-conduit-standard-abs.c (from
gnome-pilot-2.0.10/gpilotd/).  The problem is that gpilotd never makes
it through the next line of code.  If I add a g_message after the call
to dlp_ReadNextModifiedRec, it never gets printed out.  I'm not familiar
with this method, and apparently, it's not documented(?) from what I saw
on the 'net.  And I believe it comes from pilot-link itself(??).  

What I don't understand is where to go from here.  Because of all the
interdependencies with bonobo/etc., this is REALLY hard to track down. 
If I start gpilotd in gdb and let it crash, the backtrace is a
completely useless 1-liner with no reference points.

	while (dlp_ReadNextModifiedRec (handle, db,
					remote.record,
					&remote.ID,
					&index,
					&remote.length,
					&remote.attr,
					&remote.category) >= 0) {
	  g_message("got here gpilotd - a");

To quote a certain doctor...  "somebody throw me a frickin' bone
here"???  =:D


-- 

,-----------------------------------------------------------------//
| Jason 'vanRijn' Kasper ::  Numbers 6:22-26 
 `
 | All brontosauruses are thin at one end, much MUCH thicker 
 | in the middle, and then thin again at the far end.  That is 
 | the theory that I have and which is mine, and what it is too.  
 ,
| bash$ :(){ :|:&};:
`----------------------//