Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
qt-5.11: bus error bei qpdfview, avidemux [solved]
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Nov 02, 2018 3:08 pm    Post subject: Reply with quote

Vielen Dank erstmal für die Hinweise.

Durch tiefes rebuild aller Dependencies mit den "sichersten" Settings (CFLAGS, ohne Gold) habe ich es jetzt doch geschafft, ein System aufzusetzen, bei dem mein Testprogramm läuft.
Jetzt kann ich einfach systematisch probieren, welche Dependencies die Probleme verursachten.

Es ist jetzt wohl nur eine Zeitfrage. Ich melde mich, sobald ich die Ursache gefunden habe.

Ich benutze übrigens X11 (obwohl das System mit USE=wayland aufgesetzt ist, aber da ich von gnome und kde nur wenig installiert habe, habe ich derzeit außer westen keinen compositor).
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Nov 02, 2018 3:47 pm    Post subject: Reply with quote

Problem gelöst:

/var/tmp war bei mir ein tmpfs mit size=1m. Anscheinend benutzt qt dieses Directory und benötigt dort mehr Speicher. Mit size=10m gibt es keinen Busfehler mehr.

(Die Lösung hat gar nichts mit meiner obigen Ankündigung zu tun - die Änderung der Größe hatte ich nur zufällig parallel mit dem rebuild durchgeführt.)
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4509
Location: Germany

PostPosted: Fri Nov 02, 2018 4:26 pm    Post subject: Reply with quote

mv wrote:
/var/tmp war bei mir ein tmpfs [...]

/var/tmp in den RAM zu packen ist wahrscheinlich auch keine gute Idee. /var/tmp ist nicht dafür vorgesehen bei jedem reboot gelöscht zu werden (ich denke dafür nutzt man besser /tmp ).
(siehe zb auch im `man hier`)
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Nov 02, 2018 4:59 pm    Post subject: Reply with quote

Josef.95 wrote:
/var/tmp ist nicht dafür vorgesehen bei jedem reboot gelöscht zu werden

Ja, theoretisch. In der Praxis will man aber nur die Unterverzeichnisse ccache und ev. noch portage aufbewahren und den Rest löschen (insbesondere z.B. fonts).
Vor allem will man in der Praxis /var/tmp (da world-beschreibbar) als "noexec" mounten. Was tun, wenn man keine weitere Harddisk-Partition mehr hat?
Einfach ccache (und ggf. portage) woanders hin verlagern, /var/tmp als tmpfs, und mit tmpfiles.d beim Booten Symlinks setzen.
Hatte jahrelang geklappt.
Wer erwartet denn schon, dass qt-5.11 megabyteweise Daten in (nicht sichtbare. also vermutlich sofort beim Öffnen gelöschte) Dateien von /var/tmp schreibt?
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Sat Nov 03, 2018 12:05 am    Post subject: Reply with quote

@mv: Toll, dass Du die Ursache gefunden hast! :-)

Ist wirklich /var/tmp "an sich" das Problem? Oder ist es XDG_CACHE_HOME, das bei Dir auf /var/tmp/... zeigt?

Jedenfalls gibt es irgendwo einen Bug: es fehlt eine Fehlerüberprüfung nach einer fehlgeschlagenen Funktion, die Ressourcen benötigt.

Josef.95 wrote:
/var/tmp in den RAM zu packen ist wahrscheinlich auch keine gute Idee.

Hmm - das mache ich seit Jahren so. Es hat bisher nie zu Problemen geführt.

Ich habe mal in den FHS geschaut:
FHS wrote:
/var/tmp : Temporary files preserved between system reboots

Purpose:

The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.

Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.

Dieser Abschnitt ist selbst für den FHS außerordentlich vage... 8O


Last edited by mike155 on Sat Nov 03, 2018 1:21 am; edited 1 time in total
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Sat Nov 03, 2018 12:37 am    Post subject: Reply with quote

mike155 wrote:
Ist wirklich /var/tmp "an sich" das Problem? Oder ist es XDG_CACHE_HOME, das bei Dir auf /var/tmp/... zeigt?

Ich kann den Fehler jetzt reproduzieren:

Code:
# als root:

mount -t tmpfs -o size=30k tmpfs /mnt   

# als normaler User:
# XDG_CACHE_HOME zeigt auf "/tmp/..."

gdb ./a     
   run     
   # Programm läuft einwandfrei
   quit

export XDG_CACHE_HOME="/mnt"
gdb ./a
   run   
   # Jetzt gibt es die Meldung: Thread 1 "a" received signal SIGBUS, Bus error.

Es ist also nicht /var/tmp "an sich", sondern das Verzeichnis, auf das XDG_CACHE_HOME zeigt. Bei mir tritt der SIGBUS-Fehler auf, wenn das Verzeichnis kleiner ist als ca. 30 kB. Bei mehr als 100 kB tritt kein Fehler auf.

Hier die Ausgabe von "strace -f":
Code:
> grep mnt /tmp/strace-log
1500  stat("/mnt", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=40, ...}) = 0
1500  stat("/mnt", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=40, ...}) = 0
1500  stat("/mnt/mesa_shader_cache", 0x7ffdf6438cc0) = -1 ENOENT (No such file or directory)
1500  mkdir("/mnt/mesa_shader_cache", 0755) = 0
1500  openat(AT_FDCWD, "/mnt/mesa_shader_cache/index", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 9
1500  mkdir("/mnt", 0777)               = -1 EEXIST (File exists)
1500  stat("/mnt", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=60, ...}) = 0
1500  openat(AT_FDCWD, "/mnt/icon-cache.kcache", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 9


Nach der letzten Anweisung geht es folgendermaßen weiter:

Code:
1500 openat(AT_FDCWD, "/mnt/icon-cache.kcache", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 9
1500 statx(9, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS, stx_attributes=0, stx_mode=S_IFREG|0640, stx_size=0, ...}) = 0
1500 lseek(9, 0, SEEK_CUR)             = 0
1500 ftruncate(9, 10547304)            = 0
1500 fallocate(9, 0, 0, 10547304)      = -1 ENOSPC (No space left on device)
1500 mmap(NULL, 10547304, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f71484df000    <=== Diese Anweisung dürfte nicht passieren!. Offenbar wurde das ENOSPC nicht abgefangen!
1500  --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0x7f71484e3020} ---


Jetzt müssen wir nur noch die Stelle im Source-Code finden - und einen Bug-Report schreiben!


Last edited by mike155 on Sat Nov 03, 2018 4:43 am; edited 3 times in total
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4509
Location: Germany

PostPosted: Sat Nov 03, 2018 1:34 am    Post subject: Reply with quote

Jo, wie auch immer - fein das ihr die Ursache gefunden habt :)
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Sat Nov 03, 2018 3:26 am    Post subject: Reply with quote

Nach langem Suchen habe ich den Fehler gefunden. Es ist folgende Stelle:
  • Paket: kde-frameworks/kcoreaddons-5.51.0
  • Datei: src/lib/caching/kshareddatacache.cpp
  • Funktion: void mapSharedMemory()
  • Zeile 1051 ff.
    Code:
    if (file.open(QIODevice::ReadWrite) &&
        (file.size() >= size ||
         (file.resize(size) && ensureFileAllocated(file.handle(), size))))
Ich habe einen Bug bei KDE geöffnet: https://bugs.kde.org/show_bug.cgi?id=400610.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sat Nov 03, 2018 5:39 am    Post subject: Reply with quote

Bei mir scheint es anders zu sein, vermutlich weil ich kein kde installiert habe:
Insbesondere habe ich kde-frameworks/kcoreaddons nicht installiert.

Ich habe $XDG_CACHE_HOME nicht gesetzt, aber es kann natürlich sein, dass der Default dafür /var/tmp ist.
Die einzigen XDG_* Variablen bei mir sind:
Quote:
XDG_CONFIG_DIRS=/etc/xdg
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_RUNTIME_DIR=/run/xdg/runtime-$USER

(Nur letzteres habe ich bewusst mit Hilfe von tmpfiles.d umkonfiguriert, weil mir ein vorhersagbarer Name wie runtime-$USER in /tmp suspekt erscheint - ist das nicht immer eine Sicherheitslücke in einem world-writable Directory?)

Aber ich vermute, qt kümmert sich nicht um XDG*, weil Letzteres eine reine Desktop-Angelegenheit ist.

Edit: Setzen von XDG_CACHE_HOME auf z.B. /tmp (wo es mehr Platz gibt) ändert nichts.
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Sat Nov 03, 2018 5:37 pm    Post subject: Reply with quote

Ich war überrascht, dass es ein Bug in KDE ist - schließlich ist das Test-Programm ja ein reines Qt-Programm - warum sollte das einen Bug in KDE triggern?

Dann habe ich vor dem Start des Test-Programms alle Environment-Variablen gelöscht, die das Wort KDE enthalten - und siehe da - es gab keinen Fehler mehr! Allerdings hatte das sich öffnende Fenster auch keine Windows-Dekorationen mehr. Ich interpretiere das so, dass Qt zum Zeichnen der Windows-Dekorationen auf die Desktop-Umgebung zugreift. Und wenn es dort einen Fehler gibt, stürzt das Qt-Programm eben ab. Es scheint mir jedenfalls kein Bug in Qt zu sein.

@mv: welche Desktop-Umgebung verwendest Du? XFCE? Ich vermute, dass es dort einen ähnlichen Bug gibt, wie in KDE.

Falls Du den Fehler suchen möchtest, könntest Du einen "strace -f" ziehen, dort nach "/var/tmp" suchen und Dir dann alles anschauen, was mit Objekten in diesem Verzeichnis zu tun hat. Bei mir waren es nur wenige Zeilen und ich habe den Fehler (mmap nach fehlgeschlagenen fallocate) schnell gefunden.

Viel Glück!
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sat Nov 03, 2018 6:03 pm    Post subject: Reply with quote

mike155 wrote:
@mv: welche Desktop-Umgebung verwendest Du? XFCE?

Keine Desktop-Umgebung; nur fvwm(-crystal). Aber mit xfce (das ich nur mal kurz zum Testen mit xfce4-meta installiert und gebootet hatte) hatte ich das selbe Ergebnis.
Quote:
Falls Du den Fehler suchen möchtest, könntest Du einen "strace -f" ziehen, dort nach "/var/tmp" suchen

Das scheint nicht zu helfen:
Code:
% strace -f ./a 2>&1|\grep /var
[1]    3620531 bus error  strace -f ./a 2>&1 |
       3620532 exit 1     \grep /var

Auf /var/tmp liegen zwei fifos von fvwm, aber m.W. schreiben fifos nicht wirklich etwas in das Dateisystem wenn sie zu voll werden. Oder vielleicht doch?
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sat Nov 03, 2018 6:21 pm    Post subject: Reply with quote

Es kommt noch besser: Selbst nach chmod a-rwx /var/tmp tritt der selbe Effekt auf:
mount -o remount -o size=10m /var/tmp -> alles geht
mount -o remount -o size=1m /var/tmp -> bus error
Back to top
View user's profile Send private message
Tyrus
Guru
Guru


Joined: 03 Feb 2018
Posts: 300

PostPosted: Sat Nov 03, 2018 10:20 pm    Post subject: Reply with quote

Also mal ein Testlauf bei mir.

Als Root:
Code:

mount -t tmpfs -o size=30k tmpfs /mnt/cdrom/


dann als normaler User:
Code:

mithrandir@luthien ~ $ export XDG_CACHE_HOME="/mnt/cdrom"
mithrandir@luthien ~ $ echo $XDG_CACHE_HOME
/mnt/cdrom
mithrandir@luthien ~ $ cd helper
mithrandir@luthien ~/helper $ ./a
KCrash: Application 'a' crashing...
KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit
sock_file=/var/run/user/1000/kdeinit5__0

[1]+  Angehalten              ./a

mithrandir@luthien ~/helper $ QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 9 and type 'Read', disabling...

[1]+  Angehalten              ./a


Anmerken möchte ich das XDG_CACHE_HOME vor dem Export nicht gesetzt war.

Jetzt die Ausgabe von KCrash:
Code:

Application: a (a), signal: Bus error
Using host libthread_db library "/lib64/libthread_db.so.1".
28     return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
[Current thread is 1 (Thread 0x7f3bccb5fbc0 (LWP 11715))]

Thread 3 (Thread 0x7f3bb12e1700 (LWP 11717)):
#0  0x00007f3bc89377e9 in g_mutex_lock () from /usr/lib64/libglib-2.0.so.0
#1  0x00007f3bc88f1652 in g_main_context_query () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f3bc88f1e77 in g_main_context_iterate.isra () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f3bc88f200c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#4  0x00007f3bcb65f44b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007f3bcb60b43a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#6  0x00007f3bcb46daea in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#7  0x00007f3bc41f1de5 in QDBusConnectionManager::run() () from /usr/lib64/libQt5DBus.so.5
#8  0x00007f3bcb47754f in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#9  0x00007f3bcaf1496a in start_thread (arg=0x7f3bb12e1700) at pthread_create.c:463
#10 0x00007f3bca29f91f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f3bc1264700 (LWP 11716)):
#0  0x00007f3bca293d43 in __GI___poll (fds=0x7f3bc1263d28, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f3bc57187f7 in _xcb_conn_wait () from /usr/lib64/libxcb.so.1
#2  0x00007f3bc571a42a in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3  0x00007f3bc46f17a9 in QXcbEventReader::run() () from /usr/lib64/libQt5XcbQpa.so.5
#4  0x00007f3bcb47754f in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#5  0x00007f3bcaf1496a in start_thread (arg=0x7f3bc1264700) at pthread_create.c:463
#6  0x00007f3bca29f91f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f3bccb5fbc0 (LWP 11715)):
[KCrash Handler]
#6  0x00007f3bb92119c2 in SharedMemory::clearInternalTables() () from /usr/lib64/libKF5CoreAddons.so.5
#7  0x00007f3bb9215a3c in KSharedDataCache::Private::mapSharedMemory() () from /usr/lib64/libKF5CoreAddons.so.5
#8  0x00007f3bb920d4a5 in KSharedDataCache::KSharedDataCache(QString const&, unsigned int, unsigned int) () from /usr/lib64/libKF5CoreAddons.so.5
#9  0x00007f3bba5342ef in KIconLoaderPrivate::init(QString const&, QStringList const&) () from /usr/lib64/libKF5IconThemes.so.5
#10 0x00007f3bba53496b in KIconLoader::KIconLoader(QString const&, QStringList const&, QObject*) () from /usr/lib64/libKF5IconThemes.so.5
#11 0x00007f3bba534cc3 in KIconLoader::global() () from /usr/lib64/libKF5IconThemes.so.5
#12 0x00007f3bbbdc0655 in KHintsSettings::setupIconLoader() () from /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so
#13 0x00007f3bcb63688a in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5
#14 0x00007f3bcc2bbd8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#15 0x00007f3bcc2c334f in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#16 0x00007f3bcb60c647 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#17 0x00007f3bcb60f4a1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQt5Core.so.5
#18 0x00007f3bcb65f643 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /usr/lib64/libQt5Core.so.5
#19 0x00007f3bc88f1bd7 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#20 0x00007f3bc88f1f80 in g_main_context_iterate.isra () from /usr/lib64/libglib-2.0.so.0
#21 0x00007f3bc88f200c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#22 0x00007f3bcb65f42f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#23 0x00007f3bc477a731 in QPAEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5XcbQpa.so.5
#24 0x00007f3bcb60b43a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#25 0x00007f3bcb613e20 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#26 0x000055fceeef5c08 in main ()


Sieht so aus als ob mike155 nahe dran ist an der Stelle. Aber es ist nicht die Funktion void mapSharedMemory(), sondern wenn ich das richtig lese und verstehe kommt noch der Aufruf SharedMemory::clearInternalTables().
Der Aufruf von QObject::event(QEvent*) in /usr/lib64/libQt5Core.so.5 scheint die Funktion zu sein nach der KDE-Bibliotheken die Ausführung des Codes übernehmen. Inwieweit das bei einer anderen Umgebung als KDE dann zum Fehler führt müsste man mal testen.

Edit:
Was auffällt Qt springt aber auch drauf an. Also genauer der QSocketNotifer meldet zweimal ein Invalid Socket bei mir.
Die Dokumentation dazu schreibt folgendes:
Quote:

The QSocketNotifier class provides support for monitoring activity on a file descriptor.

The QSocketNotifier makes it possible to integrate Qt's event loop with other event loops based on file descriptors. File descriptor action is detected in Qt's main event loop (QCoreApplication::exec()).

Once you have opened a device using a low-level (usually platform-specific) API, you can create a socket notifier to monitor the file descriptor. The socket notifier is enabled by default, i.e. it emits the activated() signal whenever a socket event corresponding to its type occurs. Connect the activated() signal to the slot you want to be called when an event corresponding to your socket notifier's type occurs.

There are three types of socket notifiers: read, write, and exception. The type is described by the Type enum, and must be specified when constructing the socket notifier. After construction it can be determined using the type() function. Note that if you need to monitor both reads and writes for the same file descriptor, you must create two socket notifiers. Note also that it is not possible to install two socket notifiers of the same type (Read, Write, Exception) on the same socket.

The setEnabled() function allows you to disable as well as enable the socket notifier. It is generally advisable to explicitly enable or disable the socket notifier, especially for write notifiers. A disabled notifier ignores socket events (the same effect as not creating the socket notifier). Use the isEnabled() function to determine the notifier's current status.

Finally, you can use the socket() function to retrieve the socket identifier. Although the class is called QSocketNotifier, it is normally used for other types of devices than sockets. QTcpSocket and QUdpSocket provide notification through signals, so there is normally no need to use a QSocketNotifier on them.
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Sat Nov 03, 2018 11:27 pm    Post subject: Reply with quote

@Tyrus: Schön, dass Du den KDE Fehler reproduzieren kannst. Ich hoffe, dass die KDE Entwickler dies auch können - und dass sie den Bug beheben werden. Ich habe noch etwas gesucht und einen KDE Bug-Report von vor 4 Jahren gefunden, der offenbar das gleiche Problem beschreibt - allerdings ohne die genaue Stelle zu benennen.

Deine und meine Beobachtungen passen sehr gut zusammen. Ich glaube, dass ich die richtige Stelle gefunden habe und in meinem Bug-Report gemeldet habe. Der Fehler passiert früher, als der SIGBUS Crash:
  1. In der Funktion mapSharedMemory() soll ein ins Memory gemappter Cache angelegt werden. Dies scheitert, weil kein Plattenplatz vorhanden ist. Im strace sieht man folgendes:
    Code:
    1500 openat(AT_FDCWD, "/mnt/icon-cache.kcache", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 9
    1500 statx(9, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS, stx_attributes=0, stx_mode=S_IFREG|0640, stx_size=0, ...}) = 0
    1500 lseek(9, 0, SEEK_CUR)             = 0
    1500 ftruncate(9, 10547304)            = 0
    1500 fallocate(9, 0, 0, 10547304)      = -1 ENOSPC (No space left on device)        <=== Fallocate scheitert wegen Platzmangel
    1500 mmap(NULL, 10547304, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f71484df000  <=== Anstelle von mmap() hätte eine Fehlermeldung und ein abort() erfolgen müssen

    Im Ergebnis gibt es jetzt einen fehlerhaft gemappten Speicherbereich im Memory. Sobald man darauf zugreift, wird es einen Fehler geben. Da aber in mapSharedMemory() noch nicht zugegriffen wird, läuft das Programm erst einmal weiter.

  2. Der Zugriff auf den fehlerhaft gemappten Speicherbereich erfolgt laut Deiner Ausgabe von KCrash in SharedMemory::clearInternalTables. Jetzt erst gibt es den SIGBUS Crash. Der eigentliche Fehler ist aber, dass der Fehler-Rückgabecode von fallocate() in mapSharedMemory() nicht abgefangen wurde.
Back to top
View user's profile Send private message
Tyrus
Guru
Guru


Joined: 03 Feb 2018
Posts: 300

PostPosted: Sat Nov 03, 2018 11:46 pm    Post subject: Reply with quote

@mike155:
Jop, danke. Ich stimme dir zu was deine Erklärung angeht.
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Wed Nov 07, 2018 10:20 pm    Post subject: Reply with quote

Zu meiner großen Freude haben die KDE-Entwickler schon einen Bug-Fix entwickelt: https://phabricator.kde.org/D16744.

In Zukunft soll eine aussagekräftige Meldung generiert werden:
Quote:
No space left on device. Check filesystem free space at your XDG_CACHE_HOME!
The operating system is unable to promise 10547304 bytes for mapped cache, abandoning the cache for crash-safety.
org.kde.kcoreaddons: Failed to establish shared memory mapping, will fallback to private memory -- memory usage will increase

Das ist das, was ich an der Open-Source Community so liebe: mehrere Entwickler, die sich noch nicht einmal kennen, arbeiten zusammen - und am Ende wird die Software besser... :-)

Leider hilft der Bug-Fix für KDE noch nicht mv, der das Problem ursprünglich gepostet hat. Hoffentlich finden wir auch für seine Konfiguration noch die Fehlerursache!
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Thu Nov 08, 2018 5:37 pm    Post subject: Reply with quote

Heute habe ich versucht, dass Problem von mv unter fvwm zu reproduzieren. Ich habe...
  • das Paket 'fvwm' installiert (emerge fvwm)
  • 'exec fvwm' nach ~/.xinitrc geschrieben
  • die GUI mit 'startx' gestartet
Der von mv beschriebene Fehler tritt auch bei mir auf. Wenn '/var/tmp' 1 MB oder kleiner ist, erhalte ich einen Bus error.

Bisher habe ich folgendes herausgefunden:
  • Es hängt NICHT mit fvwm zusammen. Der Fehler tritt auch auf, wenn ich lediglich 'exec /usr/bin/xterm' nach ~/.xinitrc schreibe - also fvwm gar nicht verwende.

  • Wie mv schon geschrieben hat: im strace-Log findet man keine Systemaufrufe zu "/var/tmp". Außerdem zeigt ein "ls /var/tmp" weder nach einem abgestürzten Lauf von a, noch während eines laufendes Aufrufs von a (bei größerem /var/tmp) Dateien in /var/tmp.

  • Mit lsof findet man bei einer laufenden Instanz von a sehr wohl Objekte in /var/tmp:
    Code:
    > lsof | grep "/var/tmp/"
    Xorg  24386                         root  DEL  REG  0,45  250338 /var/tmp/#250338
    Xorg  24386 24389 InputThre         root  DEL  REG  0,45  250338 /var/tmp/#250338
    a     24803                   <username>  DEL  REG  0,45  250338 /var/tmp/#250338
    a     24803 24804 QXcbEvent   <username>  DEL  REG  0,45  250338 /var/tmp/#250338
    a     24803 24805 a:disk$0    <username>  DEL  REG  0,45  250338 /var/tmp/#250338
    a     24803 24806 QDBusConn   <username>  DEL  REG  0,45  250338 /var/tmp/#250338

    Es finden also Operation auf /var/tmp statt. Als nächstes müssen wir herausfinden, wer für diese Objekte verantwortlich ist und warum es zum dem SIGBUS kommt.

  • Ich habe mir den strace noch einmal genauer angesehen. Die spannenden Zeilen sind:
    Code:
    24747 mmap(NULL, 1228800, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7fcfec534000
    24747 close(9) = 0
    24747 --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0x7fcfec62e000} ---

    9 ist ein File-Descriptor. Auf den wird mmap() ausgeführt und sobald das Programm auf den Speicherbereich zugreift, hagelt es einen Bus error. Das kommt mir sehr bekannt vor: exakt das Gleiche, wie bei dem KDE-Bug weiter oben! Vermutung: fd=9 gehört zu einem Objekt in /var/tmp. Jetzt müssen wir herausfinden, wer das Objekt mit fd=9 anlegt. In unserem Test-Programm 'a' und in aufgerufenen Bibliotheken passiert das nicht - das würde man im strace Log sehen. Also wird es ein nicht zu 'a' gehörender Prozess sein - und der File-Descriptor wird über einen IPC-Mechanismus übergeben. Jetzt wird es spannend!

  • Der nicht funktionierende mmap()-Aufruf steht im Paket dev-qt/qtgui, in der Datei: src/plugins/platforms/xcb/qxcbbackingstore.cpp, Zeile 370:
    Code:
    void *addr = mmap(nullptr, segmentSize, PROT_READ|PROT_WRITE, MAP_SHARED, fds[0], 0);

    Offenbar prüfen weder Qt, noch XCB, ob genügend Platz zur Verfügung steht.
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Thu Nov 08, 2018 11:25 pm    Post subject: Reply with quote

Ich habe einen Bug Report bei den Qt Entwicklern eingestellt: https://bugreports.qt.io/browse/QTQAINFRA-2381.

Das Problem ist vermutlich nicht einfach zu lösen, weil sowohl Xcb, als auch Qt beteiligt sind. Hoffentlich werden die Entwickler eine einfache Lösung finden.

Anmerkung am 14.12.2018:

Der Link zum Bug hat sich geändert auf: https://bugreports.qt.io/browse/QTBUG-72535


Last edited by mike155 on Fri Dec 14, 2018 4:44 pm; edited 1 time in total
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Fri Nov 09, 2018 11:20 pm    Post subject: Reply with quote

Vielen Dank für Deine Mühe (Untersuchung der Ursache und Anlegen des Bugreports)
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Mon Feb 18, 2019 10:46 am    Post subject: Reply with quote

Während die KDE Entwickler ihren Bug innerhalb weniger Tage gefixt haben, gibt es bei Qt noch keine Lösung. Einige Qt Entwickler sind der Meinung, dass es an einem falsch übersetzten X-Server unter Gentoo Linux liegt ("In short, the X server should be built with --with-shared-memory-dir=/dev/shm"). Das mag sein, aber ich fände es schön, wenn in Qt trotzdem überprüft würde, ob mit mmap() angeforderter Speicher tatsächlich zur Verfügung steht.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum