[Xastir] Still getting crashes

[Brian D Heaton]

Jack,

	Can you check and let me know what your glibc and linuxthreads versions
are please?  You may have told me before, but as I look back through my
messages I don't see it.  

	Based on some digging in the source below is where the (at least from
what I can tell) germane pieces of the source are:

	It looks like during the write to the TNC (Xastir port 1) something is
bombing out.  From what I can tell so far it doesn't happen on every
write to the TNC, only some of them (Jack, please confirm that folks on
the local RF channel are seeing your station and complete packets from
you).

	That would lead me to think something in the serial connection to the
TNC (KPC-3+) is flaky.  In my previous message I suggested "-v 131"
rather than "-v 3" as there as a debug_level 128 callout in the code the
does special delays for sending a CNTL-C to the TNC.  Should that be
part of the debug_level 2 flow?

	I don't see anything that jumps out as a call being made without
initializing the mutex.  I need the read it more closely and see if
there is some strange flow on a timeout or other serial error
(especially in the middle of a send)  Thoughts? Ideas?


			THX/BDH
 



(all line numbers from CVS as of about 1100EST today)


The is the point in the "port_write" thread where the error is happening
---------------------------------------------------------
interface.c - 5083
---------------------------------------------------------
 if (port_data[port].status == DEVICE_UP) {
            // Some messiness necessary because we're using
            // xastir_mutex's instead of pthread_mutex_t's.
            pthread_mutex_t *cleanup_mutex;
                                                                                                                  
                                                                                                                  
            // Install the cleanup routine for the case where this
            // thread gets killed while the mutex is locked.  The
            // cleanup routine initiates an unlock before the thread
            // dies.  We must be in deferred cancellation mode for
            // the thread to have this work properly.  We must first
            // get the pthread_mutex_t address:
            cleanup_mutex = &port_data[port].write_lock.lock;
                                                                                                                  
            // Then install the cleanup routine:
            pthread_cleanup_push((void *)pthread_mutex_unlock, (void
*)cleanup_mutex);
                                                                                                                  
                                                                                                                  
            if (begin_critical_section(&port_data[port].write_lock,
"interface.c:port_write(1)" ) > 0)
                fprintf(stderr,"write_lock, Port = %d\n", port);
                                                                                                                  
            if ( (port_data[port].write_in_pos !=
port_data[port].write_out_pos)
                    && port_data[port].status == DEVICE_UP) {
                // We have something in the buffer to transmit!
                                                                                                                  
                                                                                                                  
------------------------------------------------------------------------------------

And here is where the error message the accompanies the EINVAL on the
MUTEX is:

-----------------------------------------------------
util.c: 3018
-----------------------------------------------------
#ifdef MUTEX_DEBUG
    // Instead of blocking the thread, we'll loop here until there's
    // no deadlock, printing out status as we go.
    do {
        ret = pthread_mutex_lock(&lock->lock);
        if (ret == EDEADLK) {   // Normal operation.  At least two
threads want this lock.
            fprintf(stderr,"%s:pthread_mutex_lock(&lock->lock) ==
EDEADLK\n", text);
            sched_yield();  // Yield the cpu to another thread
        }
        else if (ret == EINVAL) {
            fprintf(stderr,"%s:pthread_mutex_lock(&lock->lock) ==
EINVAL\n", text);
            fprintf(stderr,"Forgot to initialize the mutex
object...\n");
            problems++;
            sched_yield();  // Yield the cpu to another thread
        }
    } while (ret == EDEADLK);
                                                                                                                  
    if (problems)
        fprintf(stderr,"Returning %d to calling thread\n", problems);
#else   // MUTEX_DEBUG
    pthread_mutex_lock(&lock->lock);
#endif  // MUTEX_DEBUG
----------------------------------------------------------

On Tue, 2003-12-30 at 15:06, Jack Reilly wrote:
> Right after getting off my last I went to my APRS Desktop.  Tigermap was up 
> and some new tracks showing  ....and .....this was added to the 
> Konsolewindow:
> 
> interface.c:port_write(1):pthread_mutex_lock(&lock->lock) == EINVAL
> Forgot to initialize the mutex object...
> Returning 1 to calling thread
> write_lock, Port = 1
> 
> So far the map is still showing.
> 
> Jack   aa6vn at pacbell.net
> 
> _______________________________________________
> Xastir mailing list
> Xastir at xastir.org
> http://krypton.hscs.virginia.edu/mailman/listinfo/xastir
-- 
------------------------------------------------------------------
Brian D Heaton
Senior Network Engineer
Janus Research Group
(706) 364-9100
PGP Key Available