Re: [coldsync-hackers] Snapshot: Happier Linux

[JD Smith <jdsmith@astro.cornell.edu>]

Andrew Arensburger wrote:
> 
> On Sat, Mar 31, 2001 at 09:27:49PM -0500, JD Smith wrote:
> > Aha!  All those flakey linux serial sync speed issues have
> > dissappeared.  I can now sync at 115200 (explicitly set in .coldsyncrc)
> > without a problem.  Not sure how it was working before at all if the
> > Palm was trying to talk at 9600.
> 
>         I suspect it has something to do with deep magic in the
> kernel, possibly a combination of odd and good behaviors that
> conspired to make things work.
> 
> > I did run across a strange seg-fault though. I haven't been able to
> > replicate it, but here's the snippet of the sync:4 debugging I happened
> > to have one:
> >
> > ### Cleaning up database.
> > ### Database is open. Not resetting sync flags.
> > Running sync conduits for "".
> > Trying conduit [generic]...
> >   This conduit matches. Running "[generic]"
> >   This is a default conduit. Remembering for later.
> > Trying conduit /home/jdsmith/palm/conduits/memo-tidbits...
> > Trying conduit /home/jdsmith/palm/conduits/showtimes...
> > Running default conduit
> > "" is not a ROM database, or else I'm not ignoring it.
> > Error: GenericConduit::FirstSync: Can't open "": 4.
> > Segmentation fault
> 
>         I don't suppose you still have the core file, do you? A stack
> trace could be useful.
>         Just a random thought: are there any odd files in
> ~/.palm/backup/Attic ? It's conceivable that you somehow picked up a
> weird file that got interpreted as a .pdb file.
> 
> > I think the key here might be "Database is open", which I haven't seen
> > on anything else, and I'm not sure why it was called here, and how not
> > resetting the sync flags could contribute to a null database listing.
> > I'll keep my eyes open.
> 
>         Actually, the "Database is open" message is from the previous
> database. The empty database name is a separate problem.

Right, but that's the only difference right before the crash.  I thought
the "Database is open" logic could have been the culprit, but it doesn't
look that way.

I found a strange database in my backup directory:

MemoDB .pdb 

note the extra space.  There are other databases with spaces, so that's
not the trouble.  This one has some strange stuff in it, and was formed
at the same time as the crashed sync.  I don't have a core dump, sadly.  

But I've replicated the problem.  It triggers on something in the
"install" directory, but not always.  I think it *could* be related to a
conduit running, but since I can't replicate it, it's difficult to
know.  Here's a larger debug dump:

"ST_NSyn" is not a ROM database, or else I'm not ignoring it.
Inside mkpdbname("/home/jdsmith/.palmIII/backup","ST_NSyn")
mkpdbname:    -> "/home/jdsmith/.palmIII/backup/ST_NSyn.pdb"
Doing a fast sync
Checking local database entries.
Inside mkpdbname("/home/jdsmith/.palmIII/backup","ST_NSyn")
mkpdbname:    -> "/home/jdsmith/.palmIII/backup/ST_NSyn.pdb"
### Cleaning up database.
### Database is open. Not resetting sync flags.
Running sync conduits for "".
Trying conduit [generic]...
  This conduit matches. Running "[generic]"
  This is a default conduit. Remembering for later.
Trying conduit /home/jdsmith/palm/conduits/memo-tidbits...
Trying conduit /home/jdsmith/palm/conduits/showtimes...
Running default conduit
"" is not a ROM database, or else I'm not ignoring it.
Inside mkpdbname("/home/jdsmith/.palmIII/backup","")
mkpdbname:    -> "/home/jdsmith/.palmIII/backup/.pdb"
Error: GenericConduit::FirstSync: Can't open "": 4.
Segmentation fault (core dumped)

Again you see the "Database is open" just before the dump.  I have no
sync conduits running myself now.  ST_NSyn is a database which was just
installed from the "install" directory. 

Everytime it's run successfully, there is no such message anywhere in
the debug output.  I really think it's at least related to this dtabase
open business.

Here's what gdb tells me with the core file:

#0  run_conduits (dbinfo=0x80af550, flavor=0x80768c1 "sync",
flavor_mask=4, 
    with_spc=True, pconn=0x8096278) at conduit.c:1238
1238                                  Warn(_("Conduit %s exited
abnormally. "
(gdb) bt
#0  run_conduits (dbinfo=0x80af550, flavor=0x80768c1 "sync",
flavor_mask=4, 
    with_spc=True, pconn=0x8096278) at conduit.c:1238
#1  0x80576dd in run_Sync_conduits (dbinfo=0x80af550, pconn=0x8096278)
    at conduit.c:1315
#2  0x804ba33 in run_mode_Standalone (argc=0, argv=0xbffffad0)
    at coldsync.c:1008
#3  0x804aa0a in main (argc=0, argv=0xbffffab4) at coldsync.c:383

I tried to setup the install files again to get it to elicit the same
behavior, but was unsuccessful.  This is a wierd one.  Could it really
be the Warn(_()) stuff?

JD

-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.