Mailing List Archive

On Tuesday 05 November 2002 09:42 pm, John Coiner wrote:
> Everything worked great ~72 hrs ago. Now, it runs until I change the
> channel, then crashes. Here's the stack trace:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 7176 (LWP 1624)]
> 0x08083dca in QImage::height ()
<snip>
> (gdb)
>
> What is all this stuff? Has anyone else seen this? Am I all alone? =(

That's a rather odd stacktrace. Mind updating your checkout again (just
committed something else), and turning on debugging in settings.pro, doing a
make distclean, make, etc?

Isaac

CC'ing you because you're on digest mode =)

On Tuesday 05 November 2002 10:02 pm, John Coiner wrote:
> some more info:
>
> * The crash happens, without changing the channel, if I press 'i' to see
> the program info.

So, it's the OSD.

> * 'filldata.cpp' is the only place in the code where we use QValueList
> stuff.
>
> Maybe this is related to the fact that I have not updated the program
> info database in eons.

It _really_ sounds like a stale dependency or something.. I've been changing
the OSD code quite a bit, and I haven't been able to get build dependencies
working properly with qmake.. The OSD object has changed size in recent
commits, and the libmythtv stuff doesn't auto-recompile when that happens.
It hopefully _should_ go away if you do a make clean..

> Now mythfilldatabase is locking up, more info on that soon...

Someone else reported this just recently, too.. Don't know what that is yet,
though.

Isaac

some more info:

* The crash happens, without changing the channel, if I press 'i' to see
the program info.

* 'filldata.cpp' is the only place in the code where we use QValueList
stuff.

Maybe this is related to the fact that I have not updated the program
info database in eons.

Now mythfilldatabase is locking up, more info on that soon...

-- john

On Tuesday 05 November 2002 11:13 pm, John Coiner wrote:
> make clean didn't fix the mythtv segfault. I also tried a fresh cvs
> checkout into an empty directory, which had the same problem.

Damn. That was really my only idea. :( It's definately something OSD
related, though.. Working great for me.

> 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:

Does my most recent checkin fix that? I reverted part of a change to
filldata.cpp that went in a couple days ago.

Isaac

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

On Tuesday 05 November 2002 11:13 pm, John Coiner wrote:
> make clean didn't fix the mythtv segfault. I also tried a fresh cvs
> checkout into an empty directory, which had the same problem.

Ok, I think I fixed this -- the new OSD code wasn't checking for null strings
like the old stuff was. If you hadn't updated your program database in ages,
it would've been sending empty data to the OSD to display, causing this.

I hope.

Isaac

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > Now mythfilldatabase is locking up, more info on that soon...
>
> Someone else reported this just recently, too.. Don't know
> what that is yet,
> though.

Updated using CVS, and it seems to be working better; still waiting
for the zap2it data to finish downloading, but it's not looping after
grabbing the first days data like it was before.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPcist/c1NpCTlP0JEQI4pACgj4YEW+c+ho9z2ANmzPvhzgWncO8An3+e
fU2+IJC9OHQ+G84n3atPgSqt
=NbWW
-----END PGP SIGNATURE-----