When changing channels with MythTV (using the ivtv driver), it segfaults. Reproducible: Always Steps to Reproduce: 1.Load MythTV 2.Change Channel 3.Watch Crash
Created attachment 148020 [details] Backtrace
Created attachment 148021 [details] emerge --info
version of MySQL and QT?
(In reply to comment #3) > version of MySQL and QT? > MySQL version is dev-db/mysql-5.0.56 and Qt version is x11-libs/qt-3.3.8-r4 I also have x11-libs/qt-4.4.0_beta installed but I cant imagine that affecting mythtv since it uses qt3.
Well, I've got the same version of Qt and 5.0.54 of MySQL. Works fine for me. Considering we're on different versions of MySQL and the last 3 frames of the crash are in MySQL, I'm going to kick it over to those guys.
I have the same issue with segfaults from mythtv when changing channels.
And backing off versions of mysql fixes this or not?
(In reply to comment #7) > And backing off versions of mysql fixes this or not? > Well, I tried, but the automake fails when I try to downgrade to 5.0.54. ***** automake ***** ***** automake --add-missing --copy --foreign configure.in:37: required file `../ltmain.sh' not found
(In reply to comment #7) > And backing off versions of mysql fixes this or not? > So I got 5.0.54 to compile. IT now segfaults before the frontend can even finish loading.
Please rebuild mysql w/ CFLAGS="${CFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug keepwork" USE="${USE} test" Then step up to the third stack frame after you get a new coredump, and check for null pointers being given to MySQL, by MythTV or Qt.
Created attachment 148652 [details] new backtrace Sorry, I'm not entirely sure what you mean by that, but I recompiled mysql with those options and got a new backtrace.
It doesn't look like you did. It should have given you sourcecode filenames and line numbers. Once you do have a backtrace with those, fire up gdb, and instead of printing a backtrace, use up to select the third stack frame, and them examine the variables in there (look at the gdb docs).
(In reply to comment #12) > It doesn't look like you did. It should have given you sourcecode filenames and > line numbers. Once you do have a backtrace with those, > > fire up gdb, and instead of printing a backtrace, use up to select the third > stack frame, and them examine the variables in there (look at the gdb docs). > #3 0x00002aaaaaf30d0a in ?? () from /usr/lib/libmysqlclient.so.15 (gdb) list 392 { 393 VERBOSE(VB_IMPORTANT, QString( 394 "Error: Failed to parse --generate-preview " 395 "param '%1'").arg(param)); 396 } 397 398 return ok; 399 } 400 401 int main(int argc, char **argv) Is that what you're talking about? I read through the gdb doc frames section.
That listing isn't _anywhere_ in MySQL. The address you printed there also isn't consistent with your previous traces. 1. CFLAGS="-march=k8 -O2 -pipe -ggdb" \ CXXFLAGS="-march=k8 -O2 -pipe -ggdb" \ FEATURES="keepwork splitdebug" \ USE="debug" \ emerge mysql =qt-3.3* mythtv 2. ulimit -c unlimited 3. run $BINARY 4. cause bug 5. gdb $BINARY $CORE 6. 'set logging file backtrace.log' 7. 'set logging on' 8. 'thread apply all bt full' Paste the full output from #7 (which will also be in backtrace.log) into this bug, and look for a null pointer in it - I suspect that Qt or MythTV is passing a null pointer in as the argument for a prepared statement.
Thank you for the instructions, I wasnt following you. I have to backtrace.log and I see all a null pointer in there (I think). Tragically I can't make much sense of it all. Anyhow, I uploaded the file.
Created attachment 148681 [details] backtrace.log
I believe I am getting the same SEGFAULT described in this bug. MythTV is now completely unusable - mythbackend SEGFAULTs immediately upon starting, with a backtrace similar to what's shown above (terminating at _db_return_ () from /usr/lib/libmysqlclient.so.15). I have the debugging symbols compiled, and stepped through the previous calls. Looking at the variables in the functions, I don't see anything obvious happening. It appears it might be an issue with Qt/MySQL on AMD64, since that is what I am running also. QT: 3.3.8-r4 (and 4.3.3) MySQL: 5.0.54 (same thing happens with 5.0.56) MythTV: 0.21_p17100 If I have a bit more time, I'll look through the debugging again. Let me know if you want anything specific.
Ok I think I've got some really useful info. MySQL appears to crash within the debugging functions, specifically _db_return_ in dbug.c:828 (see attachment). For me, tentatively, **it appears to work if MySQL is NOT emerged with the debug flag.** The code in dbug.c is 826 #ifndef THREAD 827 if (state->framep != NULL) 828 state->framep = (char **) *state->framep; 829 #endif which doesn't make too much sense to me. I have attached a backtrace of that thread, with file/line numbers.
Created attachment 153259 [details] Hopefully a more informative backtrace of the problem Crashing of MythTV (mythbackend) due to libmysqlclient problems.
Upstream mysql redid that part of the codebase recently, please reset with the latest arch release of dev-db/mysql (5.0.70).
