Andrew Cagney wrote:
> >   8983 fetchmail RET   read 24/0x18
> >   8983 fetchmail CALL  read(0x3,0x18af000,0x5)
> 
> HERE
> 
> I think the errno -3 is due to the cntrl-c.

-3 is ERESTART. It's kernel internal thing, the errno is never actually
delivered to userland, it just appears in ktrace.

Don't you happen to have "old" (like more than 6 months) kdump?
kdump contains special code for such ktrace records, and it should
print 'RET read RESTART', rather than 'read -1 errno -3 ...'.
The internal EJUSTRETURN/ERESTART codes changed recently, that's
why kdump should be uptodate to catch this properly.

In other words: fetchmail hangs in read(), waiting for some incoming
data to arrive. The stuff after PSIG SIGINT appears to be executed
by signal handler (terminate_run() of fetchmail?). 

Jaromir
 
> >   8983 fetchmail RET   read -1 errno -3 Unknown error: 4294967293
> >   8983 fetchmail PSIG  SIGINT caught handler=0x18107c0 mask=() code=0x0
> >   8983 fetchmail CALL  write(0x1,0x1893000,0x24)
> >   8983 fetchmail GIO   fd 1 wrote 36 bytes
> 
> The above data is jibberish as SSL is also involved (....).  Is it 
> possible to separate out SSL (using openssl and a fetchmail plugin -- I 
> know the plug-in bit just not the openssl bit).
> 
> Right now my theory is that the buffer contains the correct response 
> (0006 OK Completed) but also some leading jibberish :-(
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-