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

Also confirmed for xbmc, only runs when run via strace -f

Reporter can you please test again using RC isos or up-to-date cauldron?

CC: (none) => ennael1

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.

Do you know wich driver was the last that worked ?

CC: (none) => tmb

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
bye

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

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.

Hello,
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.
x11-driver-video-nvidia304-304.108-2.mga3.nonfree
Note: this first time, I was using kernel
kernel-desktop-3.12.7-1.mga4-1-1.mga4

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.
x11-driver-video-nvidia304-304.117-1.mga4.nonfree
And now I don't have the digikam GUI but process is running like described above.
In this second time, I am using kernel
kernel-desktop-3.12.8-1.mga4-1-1.mga4

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

CC: (none) => kalagani

ok, so there we have a possible datapoint then... I'll build a 304.108 set for others to test then...

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
http://www.mageialinux-online.org/forum/topic-17280+mageia4-rc-digikam.php#m167160
No needs to know french language,
just watch the hidden parts for the rpm -qa, lsmod, xorg log and modinfo commands!

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

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?

(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

(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.

Arggh!! It's true, I am tired or blind!
Now
1. I was already with nouveau driver
2. OK
3. OK
rpm -qa |grep nvidia
dkms-nvidia304-304.108-3.mga4.nonfree
x11-driver-video-nvidia304-304.108-3.mga4.nonfree
nvidia304-kernel-3.12.8-desktop-1.mga4-304.108-12.mga4.nonfree
nvidia304-kernel-desktop-latest-304.108-12.mga4.nonfree
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!

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.

Created attachment 4857 [details]
echo run | gdb digikam 2&> runGdbDigikam.log&

Comment on attachment 4857 [details]
echo run | gdb digikam 2&> runGdbDigikam.log&

I put this log but not very useful, thinking!

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.

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
nvidia304-doc-html-304.119-1.mga4.nonfree
nvidia304-kernel-3.12.8-desktop-1.mga4-304.119-1.mga4.nonfree
nvidia304-kernel-desktop-latest-304.119-1.mga4.nonfree
x11-driver-video-nvidia304-304.119-1.mga4.nonfree
dkms-nvidia304-304.119-1.mga4.nonfree

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

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

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

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" "$@"
by:
printf "run\nquit\n" | gdb --args "$LIBDIR/xbmc/xbmc.bin" "$@"

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

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,
Luc

CC: (none) => lmenut

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
xbmc&
[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
xbmc&
[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
digikam&
[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
nvidia304-doc-html-304.119-1.mga4.nonfree
nvidia304-kernel-desktop-latest-304.119-2.mga4.nonfree
x11-driver-video-nvidia304-304.119-1.mga4.nonfree
nvidia304-kernel-3.12.8-desktop-2.mga4-304.119-2.mga4.nonfree
dkms-nvidia304-304.119-1.mga4.nonfree

Thanks: it seems you have find the solution :+)

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.

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!

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

My arch is i586.
It seems that libp11-kit.so.0 (indirectly used by xbmc) may be the cause of the problem.

@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!

@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"

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.

@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...

Hello,

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

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).

Fix is working for me also.

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

I've reported the bug on freedesktop.org bugzilla for p11-kit: https://bugs.freedesktop.org/show_bug.cgi?id=74904

allready tracked, fixed and submitted upstream by pterjan
https://bugs.mageia.org/show_bug.cgi?id=12696

This should be fixed since 5 days with the p11-kit updates:
https://wiki.mageia.org/en/Mageia_4_Errata#nvidia_proprietary_drivers

Please reopen if problem persists.

Status: NEW => RESOLVED
Resolution: (none) => FIXED