Have you tried running the program under valgrind? Does it report any out-of-bounds heap writes?

==2973608== 8,576 bytes in 1 blocks are still reachable in loss record 1,212 of 1,213
==2973608==    at 0x483BD19: realloc (vg_replace_malloc.c:836)
==2973608==    by 0x198918: xrealloc (in /usr/bin/bash)
==2973608==    by 0x1494EE: ??? (in /usr/bin/bash)
==2973608==    by 0x1495D0: ??? (in /usr/bin/bash)
==2973608==    by 0x14984F: ??? (in /usr/bin/bash)
==2973608==    by 0x14AFE7: print_simple_command (in /usr/bin/bash)
==2973608==    by 0x14FAFF: execute_command_internal (in /usr/bin/bash)
==2973608==    by 0x1539A5: ??? (in /usr/bin/bash)
==2973608==    by 0x150042: execute_command_internal (in /usr/bin/bash)
==2973608==    by 0x151C59: execute_command (in /usr/bin/bash)
==2973608==    by 0x15396F: ??? (in /usr/bin/bash)
==2973608==    by 0x150042: execute_command_internal (in /usr/bin/bash)
==2973608== 
==2973608== 8,688 bytes in 1 blocks are still reachable in loss record 1,213 of 1,213
==2973608==    at 0x483BD19: realloc (vg_replace_malloc.c:836)
==2973608==    by 0x198918: xrealloc (in /usr/bin/bash)
==2973608==    by 0x13F92F: ??? (in /usr/bin/bash)
==2973608==    by 0x142F07: yyparse (in /usr/bin/bash)
==2973608==    by 0x1392DA: parse_command (in /usr/bin/bash)
==2973608==    by 0x19F199: parse_and_execute (in /usr/bin/bash)
==2973608==    by 0x19E8DD: ??? (in /usr/bin/bash)
==2973608==    by 0x19EAC8: source_file (in /usr/bin/bash)
==2973608==    by 0x1A94D8: source_builtin (in /usr/bin/bash)
==2973608==    by 0x14D094: ??? (in /usr/bin/bash)
==2973608==    by 0x1516F8: execute_command_internal (in /usr/bin/bash)
==2973608==    by 0x151C59: execute_command (in /usr/bin/bash)
==2973608== 
==2973608== LEAK SUMMARY:
==2973608==    definitely lost: 0 bytes in 0 blocks
==2973608==    indirectly lost: 0 bytes in 0 blocks
==2973608==      possibly lost: 0 bytes in 0 blocks
==2973608==    still reachable: 212,432 bytes in 3,397 blocks
==2973608==         suppressed: 0 bytes in 0 blocks
==2973608== 
==2973608== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Gtk-Message: 20:04:50.689: Failed to load module "canberra-gtk-module"
Gtk-Message: 20:04:50.689: Failed to load module "pk-gtk-module"
[1122/200454.234217:INFO:context.cpp(159)] Using multi-threaded message loop for Linux

*** buffer overflow detected ***: /usr/local/MATLAB/R2019b/bin/glnxa64/MATLAB terminated
Segmentation fault (core dumped)

These appear to be errors from a different process, not the main process. There is no message from the /usr/local/MATLAB/R2019b/bin/glnxa64/MATLAB process itself.

You could try deactivating/deinstalling p11kit and smartcard integration and see if that helps. The crash appears to be in that area.

I have remove p11-kit-server? Is there anything else I should do in order to deactivating/deinstalling p11kit and smartcard integration?

No idea, I'm not familiar with this technology. Let's reassign this bug and see if we can get further debugging instructions.

I removed opensc and matlab stop crashing.

The backtrace actually points to the pcsc-lite. Can you install the opensc and pcsc-lite debuginfo and try to reproduce the crash (possibly under gdb) to get better backtrace? Do you have some special USB devices/smart cards/tokens or something that could confuse pcsc-lite? Do you see the crash with pkcs11-tool too? For example with `pkcs11-tool -L`?

pkcs11-tool -L
Available slots:
No slots.



[New Thread 0x7fffacff4700 (LWP 590407)]
[New Thread 0x7fffacbf3700 (LWP 590409)]
[Thread 0x7fffc3016700 (LWP 590389) exited]
Missing separate debuginfo for /usr/local/MATLAB/R2019b/bin/glnxa64/builtins/m_interpreter/mwm_interpreter_builtinimpl.so
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/1a/f52902d8a9493d1f9a632115dcb9862436b8c5.debug
[New Thread 0x7fff64ffe700 (LWP 590410)]
[New Thread 0x7fff647fd700 (LWP 590411)]
Missing separate debuginfo for /usr/local/MATLAB/R2019b/sys/java/jre/glnxa64/jre/lib/amd64/libverify.so

Thread 34 "MATLAB" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcbf8c700 (LWP 590386)]
0x00007fff4d0002b4 in ?? ()

/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 0bc2:231a Seagate RSS LLC Expansion Portable
    |__ Port 6: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
        ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
        |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
            ID 2109:8110 VIA Labs, Inc. Hub
            |__ Port 1: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
                ID 0411:01b8 BUFFALO INC. (formerly MelCo., Inc.) 
        |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 5000M
            ID 2109:8110 VIA Labs, Inc. Hub
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        ID 0951:1666 Kingston Technology DataTraveler 100 G3/G4/SE9 G2
    |__ Port 13: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
        |__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
            ID 2109:2811 VIA Labs, Inc. Hub
        |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
            ID 2109:2811 VIA Labs, Inc. Hub
            |__ Port 1: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 12M
                ID 046d:c52b Logitech, Inc. Unifying Receiver
            |__ Port 1: Dev 6, If 2, Class=Human Interface Device, Driver=usbhid, 12M
                ID 046d:c52b Logitech, Inc. Unifying Receiver
            |__ Port 1: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M
                ID 046d:c52b Logitech, Inc. Unifying Receiver
            |__ Port 2: Dev 7, If 0, Class=Hub, Driver=hub/4p, 480M
                ID 1a40:0101 Terminus Technology Inc. Hub
                |__ Port 2: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 480M
                    ID 048d:1345 Integrated Technology Express, Inc. Multi Cardreader
                |__ Port 3: Dev 9, If 0, Class=Vendor Specific Class, Driver=btusb, 12M
                    ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth
                |__ Port 3: Dev 9, If 1, Class=Vendor Specific Class, Driver=btusb, 12M
                    ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth
                |__ Port 3: Dev 9, If 2, Class=Vendor Specific Class, Driver=btusb, 12M
                    ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth
                |__ Port 3: Dev 9, If 3, Class=Application Specific Interface, Driver=, 12M
                    ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth
                |__ Port 4: Dev 10, If 3, Class=Video, Driver=uvcvideo, 480M
                    ID 046d:0826 Logitech, Inc. HD Webcam C525
                |__ Port 4: Dev 10, If 1, Class=Audio, Driver=snd-usb-audio, 480M
                    ID 046d:0826 Logitech, Inc. HD Webcam C525
                |__ Port 4: Dev 10, If 2, Class=Video, Driver=uvcvideo, 480M
                    ID 046d:0826 Logitech, Inc. HD Webcam C525
                |__ Port 4: Dev 10, If 0, Class=Audio, Driver=snd-usb-audio, 480M
                    ID 046d:0826 Logitech, Inc. HD Webcam C525

Thank you for the logs. I would need a backtrace from the crash under gdb. I assume the matlab runs the pcsc-lite in somehow restricted environment, that does not allow it to contact the pcscd server and this is probably not correctly handled.

gdb) bt
#0  0x00007fff4d0002b4 in ?? ()
#1  0x0000000000000246 in ?? ()
#2  0x00007fff4d000160 in ?? ()
#3  0x00007fffc3ffe72c in Abstract_VM_Version::_reserve_for_allocation_prefetch ()
   from /usr/local/MATLAB/R2019b/sys/java/jre/glnxa64/jre/lib/amd64/server/libjvm.so
#4  0x00007fffcbf88ca0 in ?? ()
#5  0x00007fffc3af5f64 in VM_Version::get_processor_features() () from /usr/local/MATLAB/R2019b/sys/java/jre/glnxa64/jre/lib/amd64/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[Thread 0x7fffc3016700 (LWP 671714) exited]
Missing separate debuginfo for /usr/local/MATLAB/R2019b/bin/glnxa64/builtins/m_interpreter/mwm_interpreter_builtinimpl.so
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/1a/f52902d8a9493d1f9a632115dcb9862436b8c5.debug
[New Thread 0x7fff64ffe700 (LWP 671735)]
[New Thread 0x7fff647fd700 (LWP 671736)]
Missing separate debuginfo for /usr/local/MATLAB/R2019b/sys/java/jre/glnxa64/jre/lib/amd64/libverify.so

Thread 34 "MATLAB" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcbf8c700 (LWP 671711)]
0x00007fff4d0002b4 in ?? ()
(gdb) bt
#0  0x00007fff4d0002b4 in ?? ()
#1  0x0000000000000246 in ?? ()
#2  0x00007fff4d000160 in ?? ()
#3  0x00007fffc3ffe72c in Abstract_VM_Version::_reserve_for_allocation_prefetch ()
   from /usr/local/MATLAB/R2019b/sys/java/jre/glnxa64/jre/lib/amd64/server/libjvm.so
#4  0x00007fffcbf88ca0 in ?? ()
#5  0x00007fffc3af5f64 in VM_Version::get_processor_features() () from /usr/local/MATLAB/R2019b/sys/java/jre/glnxa64/jre/lib/amd64/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) quit()

The backtrace does not look useful here as it points to completely different place than the original one.

One more try. Did the system create a coredump from the crash? It could be useful to get more verbose backtrace.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug was accidentally closed due to a query error. Reopening.

It is possible to Matlab as trial version and Matlab. How can I get coredump from Matlab using gdb. I can also use jdb as Matlab is a Java application.

Hmm. I just installed matlab trial and I can start it without any problems with all smart card packages installed and configured with smart cards reader and yubikey connected and disconnected. From what I see so far, it is something in matlab or in your system, that is broken so I am not sure if I will be able to help more.

I am not sure how to use jdb, but you can try that.

I have installed rpm from updates-testing.

I was not able to reproduce this. But I passed this through the matlab support to their developers if it is something they can reproduce. If this will be still issue for you, please try to contact your matlab support.

It seems that upgrading pcsc-lite to upstream version 1.8.26 solves the matlab crash.

I downloaded pcsc-lite 1.8.26 from upstream and build a new package (using pcsc-lite-1.8.25-2.fc31.src.rpm as template) and installed in on my system. Then matlab doesn't crash. Previously I had the same crash as seen in this bug description.

pcsc-lite maintainers, would you please create an official package with version 1.8.26, to solve the problem to all users?


A note for matlab 2019b users:

First: Matlab doesn't find the following modules on Fedora 31:

Gtk-Message: 02:47:51.790: Failed to load module "canberra-gtk-module"
Gtk-Message: 02:47:51.790: Failed to load module "pk-gtk-module"

Setting environment variable LD_LIBRARY_PATH=/usr/lib64/gtk-2.0/modules solves the problem.

Second: The graphical desktop of matlab uses a nearly unreadable font on Fedora 31. Setting environment variable MATLAB_JAVA=/usr/lib/jvm/jre causes matlab to use the java implementation of Fedora 31 (openjdk 1.8.0) instead of the bundled java version of matlab. Then the fonts are "normal" readable.

Summary:
You can call matlab with "MATLAB_JAVA=/usr/lib/jvm/jre LD_LIBRARY_PATH=/usr/lib64/gtk-2.0/modules matlab".
Or you can modify file bin/.matlab7rc.sh in the matlab installion directory and set these variables in this file. This file is sourced by bin/matlab.

Thank you Edgar for looking into it. I will schedule the updates of pcsc-lite now (not sure why we did not get notification about a new package). Though I do not see anything related to this in changelog. Would it make sense to document the steps somewhere (on wiki?) or propose the Matlab developers to include the tweaks in their RPM package? In this closed bug, it will get lost.