Bug 12021 - digikam and xbmc will not start GUI with nvidia 304
Summary: digikam and xbmc will not start GUI with nvidia 304
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 4
Hardware: All Linux
Priority: High critical
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
Depends on: 12696
Blocks: 12079
  Show dependency treegraph
Reported: 2013-12-17 05:00 CET by Ryszard Klos
Modified: 2014-02-21 00:01 CET (History)
10 users (show)

See Also:
Source RPM:
Status comment:

echo run | gdb digikam 2&> runGdbDigikam.log& (4.96 KB, text/x-log)
2014-01-23 17:54 CET, kalagani kalagani

Description Ryszard Klos 2013-12-17 05:00:28 CET
Description of problem:
I have installed Mageia beta 1 on my older laptop(athlon dual core) with nvidia card, system is using driver 304.116 (there is no problem with video) but I couldn't start digikam and xbmc. Both programs started separately are using around 50% of CPU but nothing is happening on the screen (I have just installed beta 2 - no change). During some updates for beta 1 there was something wrong with X server configuration and system switched to Xorg driver, Kde effects did not work correctly on default settings, but digikam and xbmc start (display) correctly. I have just tested this with beta 2, and with Xorg driver for this card digikam starts with nvidia304 does not.

Version-Release number of selected component (if applicable):

How reproducible: every time.

Steps to Reproduce:
1. install system
2. run digikam
3. switch driver and run program.


Steps to Reproduce:
Manuel Hiebel 2013-12-22 20:02:35 CET

Component: Release (media or process) => RPM Packages
Blocks: (none) => 12079

Comment 1 Florian Hubold 2013-12-23 16:07:43 CET
Please only report one program per bug, as it might have totally different causes.

Confirming, seems to be the same issue as https://bugs.mageia.org/show_bug.cgi?id=11193

digikam cannot be run from terminam or menu, when run via strace it runs just fine. Also with nvidia graphics and proprietary driver.

Will test with xbmc shortly.

CC: (none) => doktor5000
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=11193

Comment 2 Florian Hubold 2013-12-23 16:30:05 CET
Also confirmed for xbmc, only runs when run via strace -f
Comment 3 Anne Nicolas 2014-01-19 21:35:51 CET
Reporter can you please test again using RC isos or up-to-date cauldron?

CC: (none) => ennael1

Comment 4 Ryszard Klos 2014-01-21 01:25:42 CET
I was checking this issue after all updates, just to make sure I have downloaded and fresh installed RC. The issue stays the same. No digikam GUI starting from menu, no errors starting from console. Runs OK with strace command.
Comment 5 Thomas Backlund 2014-01-21 09:40:14 CET
Do you know wich driver was the last that worked ?

CC: (none) => tmb

Comment 6 pat leny 2014-01-21 16:36:04 CET
I have downloaded and fresh installed RC 
No digikam GUI starting from menu, no errors starting from console. Runs OK with strace command.
my driver nvidia is the 304 ....
the kernel is 3.12.7-server-1.mga4

CC: (none) => pleny29
Hardware: x86_64 => i586

Comment 7 Ryszard Klos 2014-01-22 01:49:29 CET
First time I have tried to run digikam in Mageia 4 was the time I have reported this bug. So I do not know if it was working in alpha stages.
Comment 8 kalagani kalagani 2014-01-22 09:59:36 CET
for information:
First time I upgraded Mageia3 to Cauldron from repositories but not enough memory to download all rpm, so installation is incomplete.
Nevertheless, digikam GUI was running (just my Canon G10 camera not seen). 
So I think it is OK because Cauldron was using the last Nvidia video proprietary driver from the Mageia3 and not this for Cauldron.
Note: this first time, I was using kernel

Second time, I completed the Cauldron installation and after some problems download task-x11 was installing the last drivers for Cauldron.
I changed the "nouveau" for the proprietary Nvidia.
And now I don't have the digikam GUI but process is running like described above.
In this second time, I am using kernel

(same behavior with xbmc in the first time upgrade=OK and NOK in second time).

CC: (none) => kalagani

Comment 9 Thomas Backlund 2014-01-22 15:59:07 CET
ok, so there we have a possible datapoint then... I'll build a 304.108 set for others to test then...
Comment 10 kalagani kalagani 2014-01-22 17:03:42 CET
Thanks, I hope I thought well!
So, like I am reckless, I tried to use the driver from Mageia3 on Cauldron.
After many problems, my PC become curious: digikam 3.5 and GUI are running on Mageia3 kernel with driver "nouveau" from Cauldron, think I!
But when I made a modinfo nouveau, surprise because returned info is from Mageia3!
See my post in this french topic
No needs to know french language,
just watch the hidden parts for the rpm -qa, lsmod, xorg log and modinfo commands!
Comment 11 Thomas Backlund 2014-01-22 17:44:13 CET
ok, so in order to figure out if an older nvidia304 driver
will solve this issue...

so I've moved 304.117 to nonfree / updates_testing

and pushed 304.108 (same as in mga3) to nonfree / release

So please test if it works.

To do so, you must do a "manual downgrade":

1. switch to nouveau driver
2. uninstall all nvidia304 related rpms
   (urpme -a nvidia304)
3. make sure your media is updated and
   nvidia304 304.108 is available
4. reconfigure your hw to use nvidia304
5. test if apps still crashes
Comment 12 kalagani kalagani 2014-01-22 19:07:37 CET
1. I was already with nouveau driver
2. OK
3. OK
rpm -qa |grep nvidia
4. forced with the CCM
5. Impossible to test because installing module fails launch PC, 
I have:
nvidia304 (304.108-2.mga3.nonfree); Installing module.
Build failed. Installation skipped

So, driver nouveau is installed.

I tried a second time changing "nouveau" by "nvidia" in the /etc/X11/xorg.conf
but same message lauching PC.

Your package is tagged mga3! Normal?
Comment 13 kalagani kalagani 2014-01-22 19:12:10 CET
(In reply to kalagani kalagani from comment #12)
> 1. I was already with nouveau driver
> 2. OK
> 3. OK
> rpm -qa |grep nvidia
> nvidia304-doc-html-304.108-2.mga3.nonfree
> x11-driver-video-nvidia304-304.108-2.mga3.nonfree
> nvidia304-kernel-3.10.24-desktop-2.mga3-304.108-9.mga3.nonfree
> nvidia304-kernel-desktop-latest-304.108-9.mga3.nonfree
> dkms-nvidia304-304.108-2.mga3.nonfree
> 4. forced with the CCM
> 5. Impossible to test because installing module fails launch PC, 
> I have:
> nvidia304 (304.108-2.mga3.nonfree); Installing module.
> .........
> Build failed. Installation skipped
> So, driver nouveau is installed.
> I tried a second time changing "nouveau" by "nvidia" in the
> /etc/X11/xorg.conf
> but same message lauching PC.
> Your package is tagged mga3! Normal?

Note: my PC is in a curious state since I made trials with last driver Mga3, see my Comment 10, but I verified my PC runned well under Cauldron
uname -a
Linux localhost.xw4300 3.12.8-desktop-1.mga4 #1 SMP Sun Jan 19 04:04:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Comment 14 Thomas Backlund 2014-01-22 19:28:36 CET
(In reply to kalagani kalagani from comment #12)

> nvidia304-doc-html-304.108-2.mga3.nonfree
> x11-driver-video-nvidia304-304.108-2.mga3.nonfree
> nvidia304-kernel-3.10.24-desktop-2.mga3-304.108-9.mga3.nonfree
> nvidia304-kernel-desktop-latest-304.108-9.mga3.nonfree
> dkms-nvidia304-304.108-2.mga3.nonfree
> 4. forced with the CCM

> Your package is tagged mga3! Normal?

You seem to have mga3 medias enabled, not cauldron.

cauldron has 304.108-3.mga4.

> I tried a second time changing "nouveau" by "nvidia" in the
> /etc/X11/xorg.conf
> but same message lauching PC.

That wont work, the configuration needs to be done through mageia control  center, as its' more than one config that needs to be changed.
Comment 15 kalagani kalagani 2014-01-22 20:20:56 CET
Arggh!! It's true, I am tired or blind!
1. I was already with nouveau driver
2. OK
3. OK
rpm -qa |grep nvidia
4. forced with the CCM
5. test FAILED digikam starts but without GUI like described (xbmc also!)

more /var/log/Xorg.0.log |grep nvidia
[   124.600] (II) LoadModule: "nvidia"
[   124.601] (II) Loading /usr/lib64/xorg/extra-modules/nvidia_drv.so
[   124.657] (II) Module nvidia: vendor="NVIDIA Corporation"
[   125.832] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia

uname -a
Linux localhost.xw4300 3.12.8-desktop-1.mga4 #1 SMP Sun Jan 19 04:04:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Sorry to put you on a wrong track!
Comment 16 Ryszard Klos 2014-01-23 02:32:16 CET
Same for me, downgrading nvidia driver did not change digikam behavior.
I do not know if nvidia driver might be a problem since program runs fine with strace, so communication between digikam and nvidia seems to be fine, when everything is going slower thanks to strace. I do not know if strace is also using different libraries, if yes the problem might be in some libs, other wise it almost looks like some kind of multithreading problem, and something is called too soon before needed object or result is ready, so running this thru strace makes it work.
But this is just wild idea since I do not have source code of digikam and I have not done any testing, just assumption.
Comment 17 kalagani kalagani 2014-01-23 17:54:22 CET
Created attachment 4857 [details]
echo run | gdb digikam 2&> runGdbDigikam.log&
Comment 18 kalagani kalagani 2014-01-23 17:58:40 CET
Comment on attachment 4857 [details]
echo run | gdb digikam 2&> runGdbDigikam.log&

I put this log but not very useful, thinking!
Comment 19 Thomas Backlund 2014-01-24 02:18:53 CET
OK, so the downgrade to 304.108 did not help, so here is a new test:

I've pushed a just released 304.119 to the mirrors, with only one official fix compared to 304.117 we had before theese tests, and
that is:

- Fixed a crash when using WebGL in Firefox with a Geforce 6 GPU

So please test if the new driver behaves better or at least as
good as previous ones.
Comment 20 kalagani kalagani 2014-01-24 10:28:29 CET
Hello Thomas,

sorry, test with the 304.119 is also FAILED

So, yesterday I put log from the command
echo run | gdb digikam 2&> runGdbDigikam.log&
because with this command you have the fully digikam with GUI!

I made also log with the other command to have the fully digikam
strace -f digikam 2> straceDigikam.log
but this log is > 1000K authorized.
In this I saw a lot of ENOENT (No such file or directory) -> 266559
for ex:
access("/usr/share/icons/hicolor/64x64/actions/process-working.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/home/kalagani/.kde4/share/locale/fr/LC_SCRIPTS/libkipi/libkipi.js", R_OK) = -1 ENOENT (No such file or directory)
I don't known if it is important, amny time is lost...

rpm -qa |grep nvidia

more /var/log/Xorg.0.log |grep nvidia
[    38.498] (II) LoadModule: "nvidia"
[    38.498] (II) Loading /usr/lib64/xorg/extra-modules/nvidia_drv.so
[    38.499] (II) Module nvidia: vendor="NVIDIA Corporation"
[    39.687] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia

modinfo /lib/modules/3.12.8-desktop-1.mga4/dkms-binary/drivers/char/drm/nvidia304.ko.xz
filename:       /lib/modules/3.12.8-desktop-1.mga4/dkms-binary/drivers/char/drm/nvidia304.ko.xz
alias:          char-major-195-*
version:        304.119
supported:      external
license:        NVIDIA
alias:          pci:v000010DEd00000E00sv*sd*bc04sc80i00*
alias:          pci:v000010DEd00000AA3sv*sd*bc0Bsc40i00*
alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
alias:          pci:v000010DEd*sv*sd*bc03sc00i00*
depends:        i2c-core
vermagic:       3.12.8-desktop-1.mga4 SMP mod_unload modversions 
parm:           NVreg_EnableVia4x:int
parm:           NVreg_EnableALiAGP:int
parm:           NVreg_ReqAGPRate:int
parm:           NVreg_EnableAGPSBA:int
parm:           NVreg_EnableAGPFW:int
parm:           NVreg_Mobile:int
parm:           NVreg_ResmanDebugLevel:int
parm:           NVreg_RmLogonRC:int
parm:           NVreg_ModifyDeviceFiles:int
parm:           NVreg_DeviceFileUID:int
parm:           NVreg_DeviceFileGID:int
parm:           NVreg_DeviceFileMode:int
parm:           NVreg_RemapLimit:int
parm:           NVreg_UpdateMemoryTypes:int
parm:           NVreg_InitializeSystemMemoryAllocations:int
parm:           NVreg_UseVBios:int
parm:           NVreg_RMEdgeIntrCheck:int
parm:           NVreg_UsePageAttributeTable:int
parm:           NVreg_EnableMSI:int
parm:           NVreg_MapRegistersEarly:int
parm:           NVreg_RegisterForACPIEvents:int
parm:           NVreg_RegistryDwords:charp
parm:           NVreg_RmMsg:charp
parm:           NVreg_NvAGP:int
Comment 21 Rémi Verschelde 2014-01-24 10:39:10 CET
I can add that the nonfree/updates_testing nvidia-current driver (331.38) seems to be hit by this bug too. I only use the nvidia driver through bumblebee though, most of the time I rely on the intel one (intel/nvidia laptop, see my second entry in the QA hardware list: https://wiki.mageia.org/en/QA_iso_hardware_list ).

Will downgrade to nonfree/release's 325.15 driver to test.

CC: (none) => remi

Comment 22 Florian Hubold 2014-02-03 13:18:47 CET
Problem also exists with 325.15 after upgrade to Mageia 4, digikam only starts via prepended strace, xbmc only via prepended strace -f.

As handling two programs in one bug is quite messy, can we please split this one into two bugs, one for each of xbmc and digikam. Also the title is misleading, as not only nvidia driver 304 is affected.

Priority: Normal => High
Hardware: i586 => All
See Also: https://bugs.mageia.org/show_bug.cgi?id=11193 => (none)
Severity: normal => critical

Comment 23 Gilles Mouchard 2014-02-08 18:06:56 CET
Although the strace workaround is working well, it is slower than a normal execution of programs.
Another faster workaround is to run the affected programs under the control of GDB.

For XBMC, modify /usr/bin/xbmc:
line 114, replace:
"$LIBDIR/xbmc/xbmc.bin" "$@"
printf "run\nquit\n" | gdb --args "$LIBDIR/xbmc/xbmc.bin" "$@"

CC: (none) => gilles.mouchard
Version: Cauldron => 4

Comment 24 Luc Menut 2014-02-08 21:56:28 CET
This bug could be due to (or triggered by) an empty config file - /etc/pkcs11/pkcs11.conf - incorrectly handled by a library (AFAIK, /etc/pkcs11/pkcs11.conf is empty by default after install).
To all reporters affected by this bug, if your /etc/pkcs11/pkcs11.conf is empty (ls -l /etc/pkcs11/pkcs11.conf), could you try to remove it (as root), and report if it fixes the bug or not. If /etc/pkcs11/pkcs11.conf isn't empty and some programs doesn't launch correctly, please report too.
Please report precisely which nvidia driver version (nvidia-current 325.15, 304.119 or 173.14.39) is used, which arch (i586, x86_64), and which program works or not.

Thanks in advance,

CC: (none) => lmenut

Comment 25 kalagani kalagani 2014-02-08 22:22:47 CET
Hello Luc,
I think you have rigth!

My trials
Before removing the empty pkcs11.conf
under my account
ll /etc/pkcs11/pkcs11.conf
-rw-r--r-- 1 root root 0 mai   18  2013 /etc/pkcs11/pkcs11.conf
cat /etc/pkcs11/pkcs11.conf
[1] 10898
but none xbmc GUI, just the process:
ps -ef |grep -i xbmc
kalagani  10898  5489  0 22:03 pts/0    00:00:00 /bin/sh /usr/bin/xbmc
kalagani  10913 10898 97 22:03 pts/0    00:00:27 /usr/lib64/xbmc/xbmc.bin
kalagani  10931  5489  0 22:03 pts/0    00:00:00 grep --color -i xbmc
kill -9 10898 10913
Removing the pkcs11.conf
under root account
su -
Mot de passe : 
[root@localhost ~]# ll /etc/pkcs11/pkcs11.conf
-rw-r--r-- 1 root root 0 mai   18  2013 /etc/pkcs11/pkcs11.conf
[root@localhost ~]# \rm /etc/pkcs11/pkcs11.conf
[root@localhost ~]# ll /etc/pkcs11/pkcs11.conf
ls: impossible d'accéder à /etc/pkcs11/pkcs11.conf: Aucun fichier ou dossier de ce type
[root@localhost ~]# exit
[1] 11075
Running DIL (3.22.0) Version
DtsDeviceOpen: Opening HW in mode 0
DtsDeviceOpen: Create File Failed
libpng warning: iCCP: known incorrect sRGB profile

Youpee, xbmc and its GUI are correctly running
ps -ef |grep -i xbmc
kalagani  11075  5489  0 22:05 pts/0    00:00:00 /bin/sh /usr/bin/xbmc
kalagani  11090 11075 34 22:05 pts/0    00:02:35 /usr/lib64/xbmc/xbmc.bin
kalagani  11455  5489  0 22:12 pts/0    00:00:00 grep --color -i xbmc

Same good results with digikam and kwrite
[2] 11526
[patrick@localhost Musique]$ Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work.

kwrite urpmi.txt&
[3] 11648
Launched from console, these two and xbmc are running with its GUI!

My nvidia driver is the 304.119
rpm -qa |grep nvidia

Thanks: it seems you have find the solution :+)
Comment 26 Gilles Mouchard 2014-02-08 22:24:27 CET
On my Mageia 4 installation, File /etc/pkcs11/pkcs11.conf was empty.
I removed it and then the bug has disaspeared for XBMC (just tried nvidia 304.119 and 325.15).

Thanks a lot.
Comment 27 kalagani kalagani 2014-02-08 22:41:28 CET
Hello Luc,

and from graphic interface, xbmc and digikam with the application launcher and kwrite from Dolphin are OK also.

And my arch is x86_64
uname -a
Linux localhost.xw4300 3.12.8-desktop-2.mga4 #1 SMP Fri Jan 24 13:56:55 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Thanks to you, 
it seems on my old P4 640, the behavior is like with the previously Mageia3!
Comment 28 Thomas Backlund 2014-02-08 22:56:25 CET
Nice find.

Can some of you using nvidia-current test if the nvidia-current 331.38 in backports_testing also works if /etc/pkcs11/pkcs11.conf is removed.

If so we will switch back to it as its the upstream -longrterm branch we want
Comment 29 Gilles Mouchard 2014-02-08 22:57:44 CET
My arch is i586.
It seems that libp11-kit.so.0 (indirectly used by xbmc) may be the cause of the problem.
Comment 30 kalagani kalagani 2014-02-08 23:34:39 CET
@Thomas Backlund,

for which card this 331.38, I am using the 304.119 because my graphic board is in the "GeForce 6xxx and GeForce 7xxx cards, including the associated Quadro cards".

And which backports_testing, Core, NonFree, Tainted?
I added (x86_64) this 3 and none 331.38!
Comment 31 kalagani kalagani 2014-02-08 23:48:24 CET
@Thomas Backlund,

I found the 331.38 from the x11-driver-video-nvidia-current-331.38-1.mga4.nonfree but I believe it is not for my graphic board:
lspci |grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation NV44 [Quadro NVS 285] (rev a1)
and the 331.38 is for "GeForce 8xxx and later cards, including the associated Quadro cards"
Comment 32 Gilles Mouchard 2014-02-08 23:49:56 CET
On i586, nvidia driver 331.38 (once core/non-free backports_testing are activated) does work with XBMC when removing /etc/pkcs11/pkcs11.conf or even putting a single space character in it.
Comment 33 kalagani kalagani 2014-02-09 00:13:05 CET
@Thomas Backlund,

after restart PC the /var/log/Xorg.0.log is showing the 331.38 is not loaded, it is the 304.119...
more /var/log/Xorg.0.log |grep 304.119
[    45.026] (II) NVIDIA GLX Module  304.119  Fri Jan 17 09:50:24 PST 2014
[    45.029] (II) NVIDIA dlloader X Driver  304.119  Fri Jan 17 09:32:25 PST 2014
more /var/log/Xorg.0.log |grep 331.38
return nothing
331.38 is not for my graphic board and i am going to remove it...
Comment 34 Thierry Lefrançois 2014-02-09 17:56:48 CET

Unable to start KWrite too, I added a space caracter in /etc/pkcs11/pkcs11.conf and the problem stopped. My configuration:
# uname -a
Linux localhost 3.12.9-desktop-1.mga4 #1 SMP Sat Feb 1 18:16:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# lspci |grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9400 GT] (rev a1)               [NVIDIA GeForce 8100 to GeForce360]
It solved the Hplip start problem too.

CC: (none) => sanmerco

Comment 35 Rémi Verschelde 2014-02-09 18:26:52 CET
I can confirm that altering /etc/pkcs11/pkcs11.conf fixes issues (I didn't test thoroughly, but at least I couldn't start digikam with my nvidia GPU, and after putting a space in the config file, I can).
Comment 36 Ryszard Klos 2014-02-09 19:15:32 CET
Fix is working for me also.
Luc Menut 2014-02-09 23:34:19 CET

Depends on: (none) => 12696

Comment 37 Gilles Mouchard 2014-02-12 20:52:16 CET
While analyzing the source code in package p11-kit-0.20.1-3.mga4.src.rpm, I found the following bug that may be related to our problem:
in p11-kit/common/compat.c, in function p11_mmap_open, line 221: the comparison map->data == NULL is not correct.

Manual page of mmap says: On success, mmap() returns a pointer to the mapped area.  On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set appropriately.  On success, munmap() returns 0, on failure -1, and errno is set (probably to EINVAL).

I think that the check should look like (map->data == (void *) -1), not (map->data == NULL).
This seems to lead to an invalid munmap later in p11_mmap_close that branches unexpectedly in nvidia driver, that itself does an infinite loop, see gdb trace below with nvidia 304.119 driver.

I run xbmc from a console:
$ xbmc

Then, in another console, i attach the process xbmc.bin to gdb:
$ gdb
> attach <pid of xbmc.bin>

<<<<<<<< begin of iteration in an infinite loop within nvidia 304.199 driver >>>>>>>>>

0xafcbfee0 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfee0:  8b 15 ec c5 d0 af       mov    0xafd0c5ec,%edx
(gdb) si
0xafcbfee6 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfee6:  85 d2   test   %edx,%edx
(gdb) si
0xafcbfee8 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfee8:  74 36   je     0xafcbff20
(gdb) si
0xafcbfeea in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeea:  89 d8   mov    %ebx,%eax
(gdb) si
0xafcbfeec in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeec:  c1 e8 16        shr    $0x16,%eax
(gdb) si
0xafcbfeef in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeef:  8b 14 82        mov    (%edx,%eax,4),%edx
(gdb) si
0xafcbfef2 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfef2:  85 d2   test   %edx,%edx
(gdb) si
0xafcbfef4 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfef4:  74 2a   je     0xafcbff20
(gdb) si
0xafcbff20 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbff20:  81 c3 00 10 00 00       add    $0x1000,%ebx
(gdb) si
0xafcbff26 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbff26:  39 df   cmp    %ebx,%edi

<<<<<<<<<<< break the infinite loop by making loop condition false >>>>>>

(gdb) set $ebx = 0xfffff001
(gdb) si
0xafcbff28 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbff28:  73 b6   jae    0xafcbfee0
(gdb) si
0xafcbff2a in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbff2a:  8b 54 24 14     mov    0x14(%esp),%edx
(gdb) si
0xafcbff2e in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbff2e:  8b 44 24 18     mov    0x18(%esp),%eax
(gdb) si
0xafcbff32 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbff32:  89 10   mov    %edx,(%eax)
(gdb) si
0xafcbff34 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbff34:  e9 6e ff ff ff  jmp    0xafcbfea7
(gdb) si
0xafcbfea7 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfea7:  8b 4c 24 0c     mov    0xc(%esp),%ecx
(gdb) si
0xafcbfeab in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeab:  89 6c 24 34     mov    %ebp,0x34(%esp)
(gdb) si
0xafcbfeaf in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeaf:  89 4c 24 30     mov    %ecx,0x30(%esp)
(gdb) si
0xafcbfeb3 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeb3:  8b 4c 24 10     mov    0x10(%esp),%ecx
(gdb) si
0xafcbfeb7 in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeb7:  83 c4 1c        add    $0x1c,%esp
(gdb) si
0xafcbfeba in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfeba:  5b      pop    %ebx
(gdb) si
0xafcbfebb in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfebb:  5e      pop    %esi
(gdb) si
0xafcbfebc in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfebc:  5f      pop    %edi
(gdb) si
0xafcbfebd in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfebd:  5d      pop    %ebp
(gdb) si
0xafcbfebe in ?? () from /usr/lib/nvidia304/libGL.so.1
=> 0xafcbfebe:  ff e1   jmp    *%ecx
(gdb) si
0xb5fa2730 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2730 <munmap+0>:       89 da   mov    %ebx,%edx
(gdb) si
0xb5fa2732 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2732 <munmap+2>:       8b 4c 24 08     mov    0x8(%esp),%ecx
(gdb) si
0xb5fa2736 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2736 <munmap+6>:       8b 5c 24 04     mov    0x4(%esp),%ebx
(gdb) si
0xb5fa273a in munmap () from /lib/i686/libc.so.6
=> 0xb5fa273a <munmap+10>:      b8 5b 00 00 00  mov    $0x5b,%eax
(gdb) si
0xb5fa273f in munmap () from /lib/i686/libc.so.6
=> 0xb5fa273f <munmap+15>:      65 ff 15 10 00 00 00    call   *%gs:0x10
(gdb) si
0xb7742414 in __kernel_vsyscall ()
=> 0xb7742414 <__kernel_vsyscall+0>:    51      push   %ecx
(gdb) si
0xb7742415 in __kernel_vsyscall ()
=> 0xb7742415 <__kernel_vsyscall+1>:    52      push   %edx
(gdb) si
0xb7742416 in __kernel_vsyscall ()
=> 0xb7742416 <__kernel_vsyscall+2>:    55      push   %ebp
(gdb) si
0xb7742417 in __kernel_vsyscall ()
=> 0xb7742417 <__kernel_vsyscall+3>:    89 e5   mov    %esp,%ebp
(gdb) si
0xb7742419 in __kernel_vsyscall ()
=> 0xb7742419 <__kernel_vsyscall+5>:    0f 34   sysenter 
(gdb) si
0xb7742424 in __kernel_vsyscall ()
=> 0xb7742424 <__kernel_vsyscall+16>:   5d      pop    %ebp
(gdb) si
0xb7742425 in __kernel_vsyscall ()
=> 0xb7742425 <__kernel_vsyscall+17>:   5a      pop    %edx
(gdb) si
0xb7742426 in __kernel_vsyscall ()
=> 0xb7742426 <__kernel_vsyscall+18>:   59      pop    %ecx
(gdb) si
0xb7742427 in __kernel_vsyscall ()
=> 0xb7742427 <__kernel_vsyscall+19>:   c3      ret    
(gdb) si
0xb5fa2746 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2746 <munmap+22>:      89 d3   mov    %edx,%ebx
(gdb) si
0xb5fa2748 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2748 <munmap+24>:      3d 01 f0 ff ff  cmp    $0xfffff001,%eax
(gdb) si
0xb5fa274d in munmap () from /lib/i686/libc.so.6
=> 0xb5fa274d <munmap+29>:      73 01   jae    0xb5fa2750 <munmap+32>
(gdb) si
0xb5fa2750 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2750 <munmap+32>:      e8 04 4b 04 00  call   0xb5fe7259 <__x86.get_pc_thunk.cx>
(gdb) si
0xb5fe7259 in __x86.get_pc_thunk.cx () from /lib/i686/libc.so.6
=> 0xb5fe7259 <__x86.get_pc_thunk.cx+0>:        8b 0c 24        mov    (%esp),%ecx
(gdb) si
0xb5fe725c in __x86.get_pc_thunk.cx () from /lib/i686/libc.so.6
=> 0xb5fe725c <__x86.get_pc_thunk.cx+3>:        c3      ret    
(gdb) si
0xb5fa2755 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2755 <munmap+37>:      81 c1 ab 68 0c 00       add    $0xc68ab,%ecx
(gdb) si
0xb5fa275b in munmap () from /lib/i686/libc.so.6
=> 0xb5fa275b <munmap+43>:      8b 89 24 ff ff ff       mov    -0xdc(%ecx),%ecx
(gdb) si
0xb5fa2761 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2761 <munmap+49>:      f7 d8   neg    %eax
(gdb) si
0xb5fa2763 in munmap () from /lib/i686/libc.so.6
=> 0xb5fa2763 <munmap+51>:      65 03 0d 00 00 00 00    add    %gs:0x0,%ecx
(gdb) si
0xb5fa276a in munmap () from /lib/i686/libc.so.6
=> 0xb5fa276a <munmap+58>:      89 01   mov    %eax,(%ecx)
(gdb) si
0xb5fa276c in munmap () from /lib/i686/libc.so.6
=> 0xb5fa276c <munmap+60>:      83 c8 ff        or     $0xffffffff,%eax
(gdb) si
0xb5fa276f in munmap () from /lib/i686/libc.so.6
=> 0xb5fa276f <munmap+63>:      c3      ret    
(gdb) si
0xaf72081f in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf72081f:  8b 15 48 24 72 af       mov    0xaf722448,%edx
(gdb) si
0xaf720825 in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf720825:  65 8b 1d 00 00 00 00    mov    %gs:0x0,%ebx
(gdb) si
0xaf72082c in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf72082c:  8b 0c 13        mov    (%ebx,%edx,1),%ecx
(gdb) si
0xaf72082f in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf72082f:  8b 51 04        mov    0x4(%ecx),%edx
(gdb) si
0xaf720832 in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf720832:  4a      dec    %edx
(gdb) si
0xaf720833 in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf720833:  89 51 04        mov    %edx,0x4(%ecx)
(gdb) si
0xaf720836 in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf720836:  8b 5c 24 0c     mov    0xc(%esp),%ebx
(gdb) si
0xaf72083a in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf72083a:  8b 74 24 10     mov    0x10(%esp),%esi
(gdb) si
0xaf72083e in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf72083e:  8b 7c 24 14     mov    0x14(%esp),%edi
(gdb) si
0xaf720842 in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf720842:  8b 6c 24 18     mov    0x18(%esp),%ebp
(gdb) si
0xaf720846 in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf720846:  83 c4 1c        add    $0x1c,%esp
(gdb) si
0xaf720849 in ?? () from /usr/lib/nvidia304/tls/libnvidia-tls.so.304.119
=> 0xaf720849:  c3      ret    
(gdb) si
0xaba3ce96 in p11_mmap_close () from /lib/libp11-kit.so.0
=> 0xaba3ce96 <p11_mmap_close+38>:      8b 06   mov    (%esi),%eax
Comment 38 Gilles Mouchard 2014-02-12 21:52:39 CET
I've reported the bug on freedesktop.org bugzilla for p11-kit: https://bugs.freedesktop.org/show_bug.cgi?id=74904
Comment 39 Thomas Backlund 2014-02-12 21:57:50 CET
allready tracked, fixed and submitted upstream by pterjan
Comment 40 Florian Hubold 2014-02-21 00:01:51 CET
This should be fixed since 5 days with the p11-kit updates:

Please reopen if problem persists.

Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.