From: FFADO <ffa...@ff...> - 2010-01-03 23:25:30
|
#247: 896HD only successfully connects in jackd at 192000 -------------------------------------+-------------------------------------- Reporter: sireasoning | Owner: jwoithe Type: bug | Status: assigned Priority: major | Milestone: FFADO 2.1 Version: FFADO 2.0-rc2 (1.999.42) | Resolution: Keywords: | Device_name: Motu 896HD -------------------------------------+-------------------------------------- Comment (by jwoithe): Replying to [comment:21 sireasoning]: > I am unfamiliar with gdb but here is some of what you asked for. I could not figure out what to do with the print command though That's fine - it's a good start and we can build on that. > {{{ > # gdb /usr/bin/jackd core < > GNU gdb (GDB) 7.0-ubuntu > : > Core was generated by `jackd -R -P70 -dfirewire -r44100 -p1024 -n4'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007fd77261b563 in memcpy () from /lib/libc.so.6 > (gdb) where > #0 0x00007fd77261b563 in memcpy () from /lib/libc.so.6 > #1 0x00007fd7718cbe9a in ffado_ringbuffer_write () from /usr/lib/libffado.so.2 > #2 0x00007fd7718cd3b5 in Util::TimestampedBuffer::writeFrames(unsigned int, char*, double) () from /usr/lib/libffado.so.2 > #3 0x00007fd77192a9c7 in Streaming::MotuReceiveStreamProcessor::processPacketData(unsigned char*, unsigned int) () from /usr/lib/libffado.so.2 > #4 0x00007fd7718c18c5 in Streaming::StreamProcessor::putPacket(unsigned char*, unsigned int, unsigned char, unsigned char, unsigned char, unsigned int, unsigned int) () from /usr/lib/libffado.so.2 > : }}} Ok, it seems that the segfault occurs when something goes very wrong with the receive side of things. Conversely we've seen the double- free/corruption trigger only on the transmit side. To use the print command, one simply requests the variable name to print. The variables available are those visible to the function where gdb is currently focused. By default it will be focused on the top-most function listed in the call trace (# 0, memcpy in this case). What we need to do is move the focus to a more useful function and investigate the arguments passed to memcpy() from there. Working from the above example, use the "down" command 3 times (or is it "up" - I can never remember) to move to the processPacketData() method. We can now view the values of variables visible to that function (looking at the source code is useful at this point). In the first instance I am interested to know the values of length, data and m_last_timestamp, so we use the commands "print length", "print data" and "print m_last_timestamp". What I am suspecting is that the packets being sent to/from the 896HD are not quite the size that we are expecting. Knowing the value of the "length" variable in particular will go some way towards proving (or disproving) this theory. -- Ticket URL: <http://subversion.ffado.org/ticket/247#comment:23> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |