[mythtv] Re: crash with recent CVS

[John Coiner]

Isaac Richards wrote:
 > It _really_ sounds like a stale dependency or something.. I've been
 > changing
...
 > It hopefully _should_ go away if you do a make clean..
 >

make clean didn't fix the mythtv segfault. I also tried a fresh cvs
checkout into an empty directory, which had the same problem.

Returning to the topic of mythfilldatabase troubles... mythfilldatabase
grabs the current day's program info, then it sits using several minutes
of CPU. Five min. and counting... I assume this is a bug. Actually, 
mythfilldatabase is using half of the CPU, the rest is
used by mysqld:

   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
   203 mysql     17   0  2176 2176  1756 R    45.7  0.2   4:10 mysqld
   202 john      15   0 14768  14M  5184 R    42.5  1.9   4:29
mythfilldatabas

Attaching gdb to the running mythfilldatabase executable shows this
stack trace:

(gdb) info threads
* 1 Thread 1024 (LWP 202)  0x40b7b811 in __libc_read () at __libc_read:-1
(gdb) where
#0  0x40b7b811 in __libc_read () at __libc_read:-1
#1  0x40983adc in __DTOR_END__ () from /lib/libpthread.so.0
#2  0x40d439fd in vio_read () from /usr/lib/libmysqlclient.so.10
#3  0x40d430b3 in net_real_write () from /usr/lib/libmysqlclient.so.10
#4  0x40d432e1 in my_net_read () from /usr/lib/libmysqlclient.so.10
#5  0x40d3f03e in net_safe_read () from /usr/lib/libmysqlclient.so.10
#6  0x40d412d4 in mysql_read_query_result () from
/usr/lib/libmysqlclient.so.10
#7  0x40d4253f in mysql_real_query () from /usr/lib/libmysqlclient.so.10
#8  0x4001c29a in QMYSQLResult::reset ()
    from /usr/lib/qt/plugins/sqldrivers/libqsqlmysql.so
#9  0x405d1007 in QSqlQuery::exec () from /usr/lib/qt/lib/libqt-mt.so.3
#10 0x0804e120 in strcpy () at ../sysdeps/generic/strcpy.c:31
#11 0x0804f5bb in strcpy () at ../sysdeps/generic/strcpy.c:31
#12 0x0804fb0a in strcpy () at ../sysdeps/generic/strcpy.c:31
#13 0x08050153 in strcpy () at ../sysdeps/generic/strcpy.c:31
#14 0x40ace17d in __libc_start_main (main=0x804fd98 <strcpy+23036>, argc=1,
     ubp_av=0xbffff7e4, init=0x8049cf4 <_init>, fini=0x8054db0 <_fini>,
     rtld_fini=0x4000a534 <_dl_fini>, stack_end=0xbffff7dc)
     at ../sysdeps/generic/libc-start.c:129
(gdb)

This stack trace looks bogus, unless strcpy() really does call
QSqlQuery::exec()

-- john