| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
 Posted: Tue Jul 31, 2018 7:11 am Post subject: avidemux and qt-5.11 [solved] |
 |
|
Does anybody use avidemux w/ qt-5.11 without an immediate segfault at starting of avidemux_qt5?
gdb shows the crash happens somewhere in nested qtgui calls at a somewhat random time/place. I tried recompiling all of qt-5.11 and avidemux w/ safe flags (gcc:8.2) without success.
Not sure whether the problem is on my specific system, only, or whether avidemux itself needs a change for qt-5.11.,,
Last edited by mv on Fri Nov 02, 2018 3:52 pm; edited 1 time in total |
|
| Back to top |
|
 |
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30887
Location: here
|
| Posted: Tue Jul 31, 2018 8:00 am Post subject: |
|
|
Here avidemux start withput a problem
| Code: | $ qlist -Iv avidemux
media-libs/avidemux-core-2.7.0
media-libs/avidemux-plugins-2.7.0
media-video/avidemux-2.7.0 |
| Code: | $ qlist -Iv gcc
sys-devel/gcc-7.3.0-r3 |
| Code: | $ qlist -Iv dev-qt/*
dev-qt/designer-5.11.1
dev-qt/linguist-tools-5.11.1
dev-qt/qdbus-5.11.1
dev-qt/qtbluetooth-5.11.1
dev-qt/qtchooser-0_p20170803
dev-qt/qtconcurrent-5.11.1
dev-qt/qtcore-5.11.1
dev-qt/qtdbus-5.11.1
dev-qt/qtdeclarative-5.11.1
dev-qt/qtgraphicaleffects-5.11.1
dev-qt/qtgui-5.11.1
dev-qt/qtimageformats-5.11.1
dev-qt/qtlockedfile-2.4.1_p20171024
dev-qt/qtmultimedia-5.11.1
dev-qt/qtnetwork-5.11.1
dev-qt/qtopengl-5.11.1
dev-qt/qtpaths-5.11.1
dev-qt/qtpositioning-5.11.1
dev-qt/qtprintsupport-5.11.1
dev-qt/qtquickcontrols2-5.11.1
dev-qt/qtquickcontrols-5.11.1
dev-qt/qtscript-5.11.1
dev-qt/qtsensors-5.11.1
dev-qt/qtsingleapplication-2.6.1_p20171024
dev-qt/qtsql-5.11.1-r1
dev-qt/qtsvg-5.11.1
dev-qt/qttest-5.11.1
dev-qt/qtvirtualkeyboard-5.11.1
dev-qt/qtwayland-5.11.1
dev-qt/qtwebchannel-5.11.1
dev-qt/qtwebengine-5.11.1
dev-qt/qtwebkit-5.212.0_pre20180120
dev-qt/qtwidgets-5.11.1
dev-qt/qtx11extras-5.11.1
dev-qt/qtxml-5.11.1
dev-qt/qtxmlpatterns-5.11.1 |
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Tue Jul 31, 2018 9:04 am Post subject: |
|
|
In the GCC ChangeLog there is this part under C++: | New Languages and Language specific improvements => C++ wrote: | GCC 8 (-fabi-version=12) has a couple of corrections to the calling convention, which changes the ABI for some uncommon code:
- Passing an empty class as an argument now takes up no space on x86_64, as required by the psABI.
- Passing or returning a class with only deleted copy and move constructors now uses the same calling convention as a class with a non-trivial copy or move constructor. This only affects C++17 mode, as in earlier standards passing or returning such a class was impossible.
- WARNING: In GCC 8.1 the second change mistakenly also affects classes with a deleted copy constructor and defaulted trivial move constructor (bug c++/86094). This issue is fixed in GCC 8.2 (-fabi-version=13).
You can test whether these changes affect your code with -Wabi=11 (or -Wabi=12 in GCC 8.2 for the third issue); if these changes are problematic for your project, the GCC 7 ABI can be selected with -fabi-version=11. |
Maybe that's what happened?
You could check both avidemux and QtCore/Gui with -Wabi=11 and -Wabi=12.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again
|
| Posted: Tue Jul 31, 2018 10:26 am Post subject: ><)))°€ |
|
|
Sigh.
I wish they had at least some support for system-ffmpeg, instead of just using a bundled version with patches on top.
Anyblue, seems to work here, too, after some fiddling around (including, but not limited to making it build with system-ffmpeg (no, I did not finish that little sudden-side-project)).
Tested with Avidemux 9999, Qt 5.11.9999, and GCC 8.2.0.
As a sidey-note, it seems like at least 'media-libs/avidemux-core' is prime fodder for Bug 557992 (ninja-porting) - [TRACKER] Packages failing with CMAKE_MAKEFILE_GENERATOR="ninja".
As another sidey-note, 2.7.0 fails with recent glibc, as also mentioned in Bug 646494 - media-video/avidemux-2.7.0 needs a patch with glibc-2.27.
_________________
Kindest of regardses. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jul 31, 2018 10:48 am Post subject: |
|
|
I recompiled now in a 32 bit chroot with and without -fabi-versoin=11 and I again always get the same result (bus error).
A typical crash is here. The message "Resizing to 0 x 0" looks suspicious and indicates a wrong usage. I have the same message with qt-5.9.6 without any crash, but maybe qt-5.9.6 is just more tolerant here.
| Code: | [UI_resize] 10:41:13-176 Resizing the main window to 147x224 px
[RDR] Resizing to 0 x 0
[1] 8137 bus error avidemux3_qt5 |
Do you also see this "Resizing to 0 x 0" message?
Edit 1:
BTW, here is the last output of another run which is long after the "Resizing" message (but maybe these are separate threads...)
| Code: |
[UI_RunApp] 10:48:50-019 Load default settings if any...
[setContainer] 10:48:50-019 setting container as index 5
[AVDM_hasVolumeControl] 10:48:50-019 The current audio device doesn't support volume control
[UI_RunApp] 10:48:50-020 [autoUpdate]Current date 697 , last check = 697
[1] 21552 bus error avidemux3_qt5 |
Edit 2:
And yet another one; this time briefly before the "Resizing to 0 x 0"
| Code: | [initGUI] 10:52:34-522 OpenGL enabled at built time, checking if we should run it..
[initGUI] 10:52:34-522 OpenGL not activated, not initialized
[destroy] 10:52:34-522 Destroying preview
[renderDisplayResize] 10:52:34-522 Render to 0x0 zoom=1.0000, old one =0 x 0, zoom=1.0000, renderer=(nil)
[UI_resize] 10:52:34-523 Resizing the main window to 147x224 px
[1] 23763 bus error avidemux3_qt5 |
|
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2571
Location: Here and Away Again
|
| Posted: Tue Jul 31, 2018 11:16 am Post subject: |
|
|
I do see similar things here:
| Code: | [...]
The screen seems to be 1920 x 1080 px
[initGUI] 11:12:40-977 OpenGL enabled at built time, checking if we should run it..
[initGUI] 11:12:40-977 OpenGL not activated, not initialized
[destroy] 11:12:40-977 Destroying preview
[renderDisplayResize] 11:12:40-977 Render to 0x0 zoom=1.0000, old one =0 x 0, zoom=1.0000, renderer=(nil)
[UI_resize] 11:12:40-977 Resizing the main window to 148x221 px
[RDR] Resizing to 0 x 0
[ADM_ad_plugin] Scanning directory /usr/lib64/ADM_plugins6/audioDecoder
[...] |
I might guess that 'RDR' refers to 'renderer', and since there is probably no video loaded up yet during launch, it goes for '0x0'.
In fact, while loading up a video file, I can see:
| Code: | [UI_resize] 11:10:35-307 Resizing the main window to 1483x941 px
Paint event
[RDR] Resizing to 1280 x 720 |
Wish it didn't mess with my window sizes like that. Maybe there is an option for it, that I can't find right now. It has been a while since I played around with this one.
_________________
Kindest of regardses. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jul 31, 2018 11:44 am Post subject: |
|
|
| Chiitoo wrote: | | I do see similar things here |
Thanks. So it is something else. (There is always a window opening before crash, but it is still filled with "background" data. With qt-5.9.6 there is always a visible resize, but I think the resize happens only after the window already contains some content.)
No idea for the moment. Since it happens on my 32 and 64 bit machines, I can only hope that it is related with some other library not "matching" to qt-5.11. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jul 31, 2018 3:19 pm Post subject: |
|
|
I am now rather convinced it is a bug of qt-8.11 itself:
After compiling qt with debugging information, I found that in all 3 cases qtgui eventually dies with the backtrace
| Code: | #0 qt_memfill32 (dest=<optimized out>, dest@entry=…, value=…, count=<optimized out>, count@entry=…) at painting/qdrawhelper_sse2.cpp:272
#1 … in qt_memfill<unsigned int> (count=…, color=…, dest=…) at ../../include/QtGui/5.11.1/QtGui/private/../../../../../src/gui/painting/qdrawhelper_p.h:828
#2 qt_rectfill<unsigned int> (stride=2936, height=664, width=734, y=0, x=0, value=…, dest=<optimized out>)
at ../../include/QtGui/5.11.1/QtGui/private/../../../../../src/gui/painting/qdrawhelper_p.h:868 |
(The "…" replaces values which look sane (not like null pointers)); the height and width vary with the dimension of the render window (for which I fixed some values for testing).
It is remarkable that the crashing code is in *_sse2.cpp even if I choose -march=pentium3 (although my processor is capable of sse2 instructions I also build packages for a machine which is not...)
Of course, names are hollow words, here. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jul 31, 2018 6:21 pm Post subject: |
|
|
It seems that for the compilation of qdrawhelper_sse2.cpp the -msse2 flag is forced (which already is broken IMHO).
However, this is not the reason for the crash: I forced -msse2 to off and also have unset the corresponding define in the file:
After that the bus error happens in the non-sse2 variant a memfill template.
So probably it is not sse2 itself but the data passed to memfill which causes problems. I do not think that I am able to debug this in reasonable time. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Nov 02, 2018 3:52 pm Post subject: |
|
|
The problem was that /var/tmp was a tmpfs with size=1m.
After increasing to size=10m, the bus error vanished. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
|
| Back to top |
|
|
|
Multimedia
