Bug 235077 - [regression] x11/nvidia-driver-304: segfault in libnvidia-tls in 12.0-RELEASE but works in 11.2
Summary: [regression] x11/nvidia-driver-304: segfault in libnvidia-tls in 12.0-RELEASE...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: i386 Any
: --- Affects Some People
Assignee: Alexey Dokuchaev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-20 12:37 UTC by Lena
Modified: 2019-11-29 15:44 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (danfe)

Attachments
The patch affects only /lib/libc.so.7 I think. (452 bytes, patch)
2019-08-24 08:18 UTC, Lena 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Lena 2019-01-20 12:37:18 UTC 
After upgrade from 11.2 to 12.0 i386 (with freebsd-update and `pkg upgrade -f`),
launch of firefox (from packages for 12) caused segmentation fault:

Core was generated by `firefox'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x22aeb63f in _nv024tls () from /usr/local/lib/libnvidia-tls.so.1
(gdb) bt
#0  0x22aeb63f in _nv024tls () at /usr/local/lib/libnvidia-tls.so.1
#1  0xffbfc9ac in  ()
#2  0x21038d1e in  () at /libexec/ld-elf.so.1
#3  0x2103553b in  () at /libexec/ld-elf.so.1
#4  0x21035394 in dlopen () at /libexec/ld-elf.so.1
#5  0x01027d1f in mozilla::GetBootstrap(char const*) ()
#6  0x01006ed8 in InitXPCOMGlue() ()
#7  0x01006b2e in main ()
(gdb)

~ # pkg info -o firefox
firefox-64.0_3,1               www/firefox
~ # pkg which /usr/local/lib/libnvidia-tls.so.1
/usr/local/lib/libnvidia-tls.so.1 was installed by package nvidia-driver-304-304.137_2

I recompiled nvidia-driver-304 from port and rebooted - same error.
Launch of www/palemoon also caused segfault.

Motherboard ASUS M2NPV-MX with integrated video GeForce 6150.

I had to restore 11.2 from backup.

Same error reported by another user:
https://devtalk.nvidia.com/default/topic/1045764/sigsegv-on-freebsd-12-0-with-304-137-on-geforce-6200/
Comment 1 VVD 2019-03-13 16:27:58 UTC 
Same here with Firefox.

Hardware: P4 3GHz HT, ASUS P4P800SE, GeForce 6600 "NV43 [GeForce 6600]", FreeBSD 12.0 i386, nvidia-driver-304-304.137_2:
$ grep OPTIONS_FILE_ /var/db/ports/x11_nvidia-driver-304/options
OPTIONS_FILE_SET+=ACPI_PM
OPTIONS_FILE_UNSET+=DOCS
OPTIONS_FILE_UNSET+=FREEBSD_AGP
OPTIONS_FILE_SET+=LINUX
OPTIONS_FILE_UNSET+=PAE
OPTIONS_FILE_SET+=WBINVD

$ ls -l /usr/local/lib/libnvidia-tls.so.1
-r--r--r-- 1 root wheel 3588 Dec 14 20:59 /usr/local/lib/libnvidia-tls.so.1
$ md5 /usr/local/lib/libnvidia-tls.so.1
MD5 (/usr/local/lib/libnvidia-tls.so.1) = a875d7e0faae6ef59e3434a1ffad8969

This file is same on 11.2 i386.


P.S. I had to return to the FreeBSD 11.2 i386.
Comment 3 VVD 2019-03-14 10:16:04 UTC 
(In reply to Alex S from comment #2)
> https://lists.freebsd.org/pipermail/svn-src-all/2017-November/153892.html ?
And after this report they keep jemalloc without changes?…
Comment 4 Alex S 2019-03-14 10:44:59 UTC 
(In reply to VVD from comment #3)

> And after this report they keep jemalloc without changes?

I don't see any relevant commits or bug reports.
Comment 5 VVD 2019-03-14 10:50:45 UTC 
(In reply to Alex S from comment #4)
> I don't see any relevant commits or bug reports.
What do you mean "relevant"?
Comment 6 Alex S 2019-03-14 11:11:38 UTC 
(In reply to VVD from comment #5)

> What do you mean "relevant"?
I mean something at https://github.com/freebsd/freebsd/commits/master/libexec/rtld-elf that looks like a fix for this particular crash.
Comment 7 VVD 2019-03-14 11:35:14 UTC 
(In reply to Alex S from comment #6)

I see fix in your first link:
> JEMALLOC_ALIGNED(16);
> Lowering to 8 byte alignment fixes the crash.
Did anybody else test this? On i386?

Or may be I misunderstood something…
Comment 8 Werner Lehmann 2019-03-20 19:06:01 UTC 
I have the same problem after a fresh install of i386 FreeBSD 12.0 on an Aspire 5610 (Nvidia Geforce Go 7300) with nvidia-driver-304 and Firefox and Seamonkey. Opera works though and no other problems with any other software so far. Kodi works, which is most important to me. Everything installed from packages just a few days ago.
Comment 9 Konstantin Belousov freebsd_committer 2019-03-26 12:44:39 UTC 
Try https://reviews.freebsd.org/D19072
Comment 10 VVD 2019-04-21 16:49:45 UTC 
(In reply to Konstantin Belousov from comment #9)
> Try https://reviews.freebsd.org/D19072
Thanks!
Can you, please, explain how to test this patch on releng/12.0 i386?
Comment 11 Lena 2019-04-21 17:23:50 UTC 
I applied the patch to releng/12.0, built world. I think that the patch affects
only /lib/libc.so.7 . I uploaded the resulting patched binary libc.so.7 to

https://drive.google.com/file/d/1_To5J1DrZLiT8zrTqWeQT44lvq0TL89-/view

I still hasn't tested it. If you can test it, it'd be appreciated.
Comment 12 VVD 2019-04-21 18:05:41 UTC 
(In reply to Lena from comment #11)
Tested on VM - Firefox work fine!

Thanks!
Comment 13 Werner Lehmann 2019-04-24 12:36:11 UTC 
So when will that fix be in the ports?
Comment 14 Lena 2019-04-24 12:57:07 UTC 
> So when will that fix be in the ports?

The tested fix is to change base (world), not ports.
Comment 15 VVD 2019-04-24 13:54:05 UTC 
(In reply to Lena from comment #14)
Ye, correct questions are "when will that fix be in the head?" and "when will be MFC to stable/12 and to releng/12.0?".
Comment 16 Werner Lehmann 2019-04-24 15:16:32 UTC 
Sorry that I as an end user and non-developer I did not realize that. So hopefully this time correctly asked from my end user perspective, when will a "freebsd-update fetch install" solve the problem?
Comment 17 VVD 2019-04-24 15:20:19 UTC 
(In reply to Werner Lehmann from comment #16)
Exactly!
Comment 18 VVD 2019-05-11 21:10:39 UTC 
Just build gegl-0.4.14 for update gimp and got segfault during compile.
Found that is issue:
$ gegl test.png -o test2.png
Segmentation fault (стек памяти сброшен на диск)
$ gdb /usr/local/bin/gegl gegl.core
GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/gegl...(no debugging symbols found)...done.
[New LWP 100657]
[New LWP 100571]
[New LWP 100576]
[New LWP 100581]
Core was generated by `gegl test.png -o test2.png'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x2eb8e63f in _nv024tls () from /usr/local/lib/libnvidia-tls.so.1
[Current thread is 1 (LWP 100657)]
(gdb) bt
#0  0x2eb8e63f in _nv024tls () at /usr/local/lib/libnvidia-tls.so.1
#1  0xffbfd9b4 in  ()
#2  0x2805ad1e in  () at /libexec/ld-elf.so.1
#3  0x2805753b in  () at /libexec/ld-elf.so.1
#4  0x28057394 in dlopen () at /libexec/ld-elf.so.1
#5  0x28142374 in g_module_open () at /usr/local/lib/libgmodule-2.0.so.0
#6  0x280f5356 in  () at /usr/local/lib/libgegl-0.4.so.0
#7  0x280f520a in gegl_module_new () at /usr/local/lib/libgegl-0.4.so.0
#8  0x280f6741 in  () at /usr/local/lib/libgegl-0.4.so.0
#9  0x280f4e2d in gegl_datafiles_read_directories () at /usr/local/lib/libgegl-0.4.so.0
#10 0x280f64de in gegl_module_db_load () at /usr/local/lib/libgegl-0.4.so.0
#11 0x280a9835 in  () at /usr/local/lib/libgegl-0.4.so.0
#12 0x2850f441 in g_slist_foreach () at /usr/local/lib/libglib-2.0.so.0
#13 0x280a92bb in  () at /usr/local/lib/libgegl-0.4.so.0
#14 0x284fdc8b in g_option_context_parse () at /usr/local/lib/libglib-2.0.so.0
#15 0x280a8b31 in gegl_init () at /usr/local/lib/libgegl-0.4.so.0
#16 0x0804ac18 in main ()

But firefox work fine with patched libc.so.7!
Comment 19 Lena 2019-05-12 13:00:55 UTC 
> Just build gegl-0.4.14 for update gimp and got segfault during compile.

If you install gegl and gimp from packages with `pkg install`, does gimp work?
Opening an image, saving as .png?
Saving as .jpg with preview while choosing compression/quality?
Adjusting brightness/contrast with preview?
Comment 20 VVD 2019-05-20 18:24:15 UTC 
(In reply to Lena from comment #19)
It's headless VM, and it's don't work now after update from 12.0-p3 to 12.0-p4 - kernel panic:
start_init: trying /sbin/init
panic: vm_fault_hold: fault on nofault entry, addr: 0
cpuid = 1
time = 1558376095
KDB: stack backtrace:
#0 0x110854f at kdb_backtrace+0x4f
#1 0x10bb517 at vpanic+0x147
#2 0x10bb3cb at panic+0x1b
#3 0x1404a25 at vm_fault_hold+0x2a45
#4 0x1401f8e at vm_fault+0x5e
#5 0x1691f97 at trap_pfault+0xc7
#6 0x169154f at trap+0x3cf
#7 0xffc0315d at PTDpde+0x4165
Uptime: 1s

Boot fine with kernel 12.0-p3 and this panic with kernel 12.0-p4.
(I think it's different issue, but anyway support of i386 becomes worse and worse every day…)
Comment 21 VVD 2019-05-20 20:33:34 UTC 
(In reply to VVD from comment #20)
Found: /usr/src/UPDATING
20190515        p5      FreeBSD-EN-19:07.mds [revised]

        Fixed error in patch causing panic on i386 architecture. [SA-19:07.mds]

Will test soon.
Comment 22 VVD 2019-05-21 00:45:08 UTC 
12.0-p5 boot fine on i386.
Comment 23 VVD 2019-05-21 12:33:12 UTC 
(In reply to Lena from comment #19)
Tested with self-builded gimp and gegl: error during export to jpg with x11/nvidia-driver-304 installed (and with your libc.so.7). Without x11/nvidia-driver-304 export work fine.

"pkg install gegl gimp" installing gegl-0.4.12_3 and gimp-2.10.8,2, but in ports gegl-0.4.14_1 and gimp-2.10.10,2.
Comment 24 VVD 2019-07-11 03:11:38 UTC 
gegl was updated to 0.4.16 and it work fine now - no core dumps with nvidia-driver-304 installed.
Comment 25 Werner Lehmann 2019-08-23 09:20:59 UTC 
12.0-RELEASE-p7 and nvidia-driver-304-304.137_4 and still "core dumped" with firefox and thunderbird, so I don't see any improvement here. And unfortunately, seamonkey has disappeared from ports, but that's another issue...
Comment 26 Lena 2019-08-23 09:49:15 UTC 
(In reply to Werner Lehmann from comment #25)

If you use FreeBSD 12 i386 (not amd64) then please try the binary linked in comment 11. If firefox works then please check whether in graphics/gimp preview while choosing compression level while saving a .jpg works.
Comment 27 VVD 2019-08-23 09:58:55 UTC 
(In reply to Lena from comment #26)
Can you, plz, update this file with sources from 12.0-p10?
Comment 28 Werner Lehmann 2019-08-23 10:55:57 UTC 
Just downloaded the file, but:

root@elvis69:/lib # cp /home/werner/Downloads/libc.so.7 /lib
cp: /lib/libc.so.7: Operation not permitted
root@elvis69:/lib #

So what do I do?
Comment 29 Lena 2019-08-23 11:03:20 UTC 
(In reply to Werner Lehmann from comment #28)

# cp -p /lib/libc.so.7 /lib/libc.so.7.orig
# chflags noschg /lib/libc.so.7
Comment 30 Lena 2019-08-24 08:00:52 UTC 
P.S. For a test I tried:

# cp /lib/libc.so.7.orig /lib/libc.so.7

And thus crashed my system. :)
How I recovered it: rebooted in single user mode, at the prompt entered /rescue/sh , then (my root filesystem is on ada0s3a):

# /rescue/mount o -rw /dev/ada0s3a /
# /rescue/cp /lib/libc.so.7.orig /lib/libc.so.7
# exit

A safe way to install patched /lib/libc.so.7 would be using /rescue/cp in single user mode. Perhaps using `mv` also is safe. Set schg flag back afterwards.

I'm rebuilding world to get a new patched binary, it'll take a couple days with my single-core Athlon 64.
Comment 31 Lena 2019-08-24 08:18:38 UTC 
Created attachment 206842 [details]
The patch affects only /lib/libc.so.7 I think.
Comment 32 VVD 2019-08-24 20:36:12 UTC 
(In reply to Lena from comment #26)
Just buildworld with this patch and replaced libc.so.6 only, then reboot.
Firefox work fine with nvidia-driver-304 installed, but "gegl test.png -o test2.png" core dumped same way as in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235077#c18:
#0  0x2f7a063f in _nv024tls () at /usr/local/lib/libnvidia-tls.so.1
#1  0xffbfd994 in  ()
#2  0x2805ad1e in  () at /libexec/ld-elf.so.1
#3  0x2805753b in  () at /libexec/ld-elf.so.1
#4  0x28057394 in dlopen () at /libexec/ld-elf.so.1
#5  0x28143374 in g_module_open () at /usr/local/lib/libgmodule-2.0.so.0
#6  0x280f5cf6 in  () at /usr/local/lib/libgegl-0.4.so.0
#7  0x280f5baa in gegl_module_new () at /usr/local/lib/libgegl-0.4.so.0
#8  0x280f70e1 in  () at /usr/local/lib/libgegl-0.4.so.0
#9  0x280f57cd in gegl_datafiles_read_directories () at /usr/local/lib/libgegl-0.4.so.0
#10 0x280f6e7e in gegl_module_db_load () at /usr/local/lib/libgegl-0.4.so.0
#11 0x280a9ba5 in  () at /usr/local/lib/libgegl-0.4.so.0
#12 0x28513441 in g_slist_foreach () at /usr/local/lib/libglib-2.0.so.0
#13 0x280a9620 in  () at /usr/local/lib/libgegl-0.4.so.0
#14 0x28501c8b in g_option_context_parse () at /usr/local/lib/libglib-2.0.so.0
#15 0x280a8e71 in gegl_init () at /usr/local/lib/libgegl-0.4.so.0
#16 0x0804ac18 in main ()

After removing nvidia-driver-304 gegl work fine.

But gegl work fine with default libc.so.6 (without patch!) and with nvidia-driver-304 installed!!!
Firefox core dumps in same environment…

???
Comment 33 Lena 2019-08-24 22:08:00 UTC 
New patched binary libc.so.7 (for 12.0-RELEASE-p10 i386):
https://drive.google.com/file/d/1ZGnKqNJYYSKFqYiyCx-nv4NAk_L480z7/view

A typo in comment 30: -o rw
`mv` should be used to rename, not to move.

(In reply to VVD from comment #32)
That's a test for gegl. But does preview work in gimp installed from packages?
Comment 34 VVD 2019-08-24 22:23:10 UTC 
(In reply to Lena from comment #33)
> That's a test for gegl.
gegl test.png -o test2.png

> But does preview work in gimp installed from packages?
Didn't test gimp.
The gegl from http://pkg.freebsd.org/FreeBSD:12:i386/latest/All/gegl-0.4.16_2.txz core dumps same way.
Comment 35 Werner Lehmann 2019-08-28 12:31:43 UTC 
After following instructions from comment 29 I managed to copy libc.so.7 to /lib whichresulted in an immediate crash. There was no other way to stop the system than a cold reboot, resulting in a dirty filesystem, now unable to run fsck because it says "ld-elf.so.1: /lib/libc.so.7: invalid file format"

I tried to apply the solution in comment30 and copy back the old backed up file on the dirty file system but after a reboot I always get stuck in

"ld-elf.so.1: /lib/libc.so.7: invalid file format" not even being able to use the standard shell to run fsck. So what now??? My system is unusable right now!
Comment 36 Lena 2019-08-28 12:44:53 UTC 
(In reply to Werner Lehmann from comment #35)

While entering single user mode, at the prompt for shell
instead of pressing Enter type:

/rescue/sh

Then for example:

# /rescue/mount -o rw /dev/ada0s1a /
# /rescue/cp /lib/libc.so.7.orig /lib/libc.so.7
# exit
Comment 37 Werner Lehmann 2019-08-28 13:03:41 UTC 
Thank you, but in the meantime I managed to run fsck and later copying back the original file using the FreeBSD 12 installation CD in live mode. I feel totally discouraged to mess like that with my system again now as I am an end-user. I think I don't want to engage in any further testing of that file for now. I hope you can go on without me and get the problem solved, as I am very much interested in using Firefox/Seamonkey/Thunderbird.
Comment 38 VVD 2019-09-03 23:16:39 UTC 
With default libc and nvidia-driver-204 installed, python3.7 coredumps during build x11-themes/plasma5-breeze-gtk with backtrace:

#0  0x2900c63f in _nv024tls () from /usr/local/lib/libnvidia-tls.so.1
#1  0xffbfb034 in ?? ()
#2  0x28054d1e in ?? () from /libexec/ld-elf.so.1
#3  0x2805153b in ?? () from /libexec/ld-elf.so.1
#4  0x28051394 in dlopen () from /libexec/ld-elf.so.1
#5  0x281edd92 in _PyImport_FindSharedFuncptr () from /usr/local/lib/libpython3.7m.so.1.0
#6  0x281bf944 in _PyImport_LoadDynamicModuleWithSpec () from /usr/local/lib/libpython3.7m.so.1.0
#7  0x281bf35b in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#8  0x280e2aac in _PyMethodDef_RawFastCallDict () from /usr/local/lib/libpython3.7m.so.1.0
#9  0x280e2514 in PyCFunction_Call () from /usr/local/lib/libpython3.7m.so.1.0
#10 0x2819ebdd in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#11 0x281a21fc in _PyEval_EvalCodeWithName () from /usr/local/lib/libpython3.7m.so.1.0
#12 0x280e227e in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#13 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#14 0x2819e933 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#15 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#16 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#17 0x280e21c9 in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#18 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#19 0x2819e911 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#20 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#21 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#22 0x280e21c9 in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#23 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#24 0x2819e9bb in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#25 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#26 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#27 0x280e21c9 in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#28 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#29 0x2819e9bb in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#30 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#31 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#32 0x280e21c9 in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#33 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#34 0x2819e9bb in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#35 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#36 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#37 0x280e1d67 in _PyFunction_FastCallDict () from /usr/local/lib/libpython3.7m.so.1.0
#38 0x280e19cc in _PyObject_FastCallDict () from /usr/local/lib/libpython3.7m.so.1.0
#39 0x280e3b21 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#40 0x280e3ba0 in _PyObject_CallMethodIdObjArgs () from /usr/local/lib/libpython3.7m.so.1.0
#41 0x281be1c5 in PyImport_ImportModuleLevelObject () from /usr/local/lib/libpython3.7m.so.1.0
#42 0x28198d8f in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#43 0x281a21fc in _PyEval_EvalCodeWithName () from /usr/local/lib/libpython3.7m.so.1.0
#44 0x2819860c in PyEval_EvalCode () from /usr/local/lib/libpython3.7m.so.1.0
#45 0x28195716 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#46 0x280e2aac in _PyMethodDef_RawFastCallDict () from /usr/local/lib/libpython3.7m.so.1.0
#47 0x280e2514 in PyCFunction_Call () from /usr/local/lib/libpython3.7m.so.1.0
#48 0x2819ebdd in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#49 0x281a21fc in _PyEval_EvalCodeWithName () from /usr/local/lib/libpython3.7m.so.1.0
#50 0x280e227e in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#51 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#52 0x2819e933 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#53 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#54 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#55 0x280e21c9 in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#56 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#57 0x2819e911 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#58 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#59 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#60 0x280e21c9 in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#61 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#62 0x2819e9bb in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#63 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#64 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#65 0x280e21c9 in _PyFunction_FastCallKeywords () from /usr/local/lib/libpython3.7m.so.1.0
#66 0x281a16a1 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#67 0x2819e9bb in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#68 0x28198735 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.7m.so.1.0
#69 0x280e2734 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#70 0x280e1d67 in _PyFunction_FastCallDict () from /usr/local/lib/libpython3.7m.so.1.0
#71 0x280e19cc in _PyObject_FastCallDict () from /usr/local/lib/libpython3.7m.so.1.0
#72 0x280e3b21 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#73 0x280e3ba0 in _PyObject_CallMethodIdObjArgs () from /usr/local/lib/libpython3.7m.so.1.0
#74 0x281be1c5 in PyImport_ImportModuleLevelObject () from /usr/local/lib/libpython3.7m.so.1.0
#75 0x28198d8f in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.7m.so.1.0
#76 0x281a21fc in _PyEval_EvalCodeWithName () from /usr/local/lib/libpython3.7m.so.1.0
#77 0x2819860c in PyEval_EvalCode () from /usr/local/lib/libpython3.7m.so.1.0
#78 0x281d3876 in PyRun_StringFlags () from /usr/local/lib/libpython3.7m.so.1.0
#79 0x281d3796 in PyRun_SimpleStringFlags () from /usr/local/lib/libpython3.7m.so.1.0
#80 0x281f5442 in ?? () from /usr/local/lib/libpython3.7m.so.1.0
#81 0x281f64e7 in _Py_UnixMain () from /usr/local/lib/libpython3.7m.so.1.0
#82 0x08048775 in main ()


But with patched libc it build fine.
Comment 39 Werner Lehmann 2019-10-30 12:09:37 UTC 
Hello, I would like to ask about the status of this issue, as I haven't seen any more posts about this? Will this be solved finally with 12.1, or maybe even sooner with some 12.1-RC?
Comment 40 VVD 2019-11-06 02:10:39 UTC 
Just tested on 12.1: firefox-70.0.1_1,1 work fine with default /lib/libc.so.7 and nvidia-driver-304-304.137_5 installed.
gegl work too.
Is it fixed?!
Comment 41 Lena 2019-11-06 14:51:06 UTC 
I see no change in
https://svnweb.freebsd.org/base/releng/12.1/contrib/jemalloc/include/jemalloc/internal/tsd.h?view=log
If 12.1 indeed works, I guess that 12.2 might break again.
But thank you for the heads-up.
Comment 42 Lena 2019-11-06 16:04:01 UTC 
/usr/ports/UPDATING

20191025:
  AFFECTS: users of x11/nvidia-driver (and slave ports)
  AUTHOR: danfe@FreeBSD.org

  x11/nvidia-driver* ports no longer install Linux programs and libraries,
  which had been moved to their own ports (x11/linux-nvidia-libs*).  When
  updating the driver package next time, remember to install them manually
  if you need to run Linux OpenGL programs.
Comment 43 VVD 2019-11-06 17:52:44 UTC 
(In reply to Lena from comment #42)
# pkg info -g '*nvidia*'
linux-nvidia-libs-304-304.137
nvidia-driver-304-304.137_5
nvidia-texture-tools-2.0.8.1_13

# ls -l /usr/local/lib/libnvidia-tls.so*
lrwxr-xr-x  1 root  wheel    18 Nov  6 04:02 /usr/local/lib/libnvidia-tls.so -> libnvidia-tls.so.1
-r--r--r--  1 root  wheel  3588 Nov  6 04:02 /usr/local/lib/libnvidia-tls.so.1

Firefox still work. But it was build on 12.0 before upgrade to 12.1 and nvidia drivers after.
Comment 44 Werner Lehmann 2019-11-06 21:24:33 UTC 
(In reply to Lena from comment #41)

I have just upgraded to 12.1 and Firefox and Thunderbird work now, that is great! So please don't let it break again in 12.2 like you state in your comment.
Comment 45 VVD 2019-11-27 18:59:37 UTC 
(In reply to Werner Lehmann from comment #44)
How do you load nvidia kernel module?
If I add nvidia_load="YES" to /boot/loader.conf, then my system reboot just after start kernel during boot process.
But it work fine if I load it on /etc/rc.local.
After that startx work too.
But if I run service sddm onestart, then kernel panic after few minutes of black screen.
Tested with GENERIC kernel and with custom.

Several panic stack traces:
============================================================
Nov 27 06:14:59 vvd kernel: spin lock 0x1f11c80 (callout) held by 0x9b89700 (tid 100003) too long
Nov 27 06:14:59 vvd kernel: panic: spin lock held too long
Nov 27 06:14:59 vvd kernel: cpuid = 1
Nov 27 06:14:59 vvd kernel: time = 1574824428
Nov 27 06:14:59 vvd kernel: KDB: stack backtrace:
Nov 27 06:14:59 vvd kernel: #0 0x103c50e at kdb_backtrace+0x4e
Nov 27 06:14:59 vvd kernel: #1 0xff6001 at vpanic+0x121
Nov 27 06:14:59 vvd kernel: #2 0xff5ed4 at panic+0x14
Nov 27 06:14:59 vvd kernel: #3 0xfd8824 at _mtx_lock_indefinite_check+0x54
Nov 27 06:14:59 vvd kernel: #4 0xfd8405 at _mtx_lock_spin_cookie+0xc5
Nov 27 06:14:59 vvd kernel: #5 0x100e7cb at callout_lock+0x9b
Nov 27 06:14:59 vvd kernel: #6 0x100e28e at callout_reset_sbt_on+0x6e
Nov 27 06:14:59 vvd kernel: #7 0x11e870d at tcp_timer_activate+0xed
Nov 27 06:14:59 vvd kernel: #8 0x11d8f0c at tcp_output+0x218c
Nov 27 06:14:59 vvd kernel: #9 0x11eaf0a at tcp_usr_send+0x1ea
Nov 27 06:14:59 vvd kernel: #10 0x107e090 at sosend_generic+0x400
Nov 27 06:14:59 vvd kernel: #11 0x107e3a3 at sosend+0x43
Nov 27 06:14:59 vvd kernel: #12 0x105e606 at soo_write+0x36
Nov 27 06:14:59 vvd kernel: #13 0x1056929 at dofilewrite+0x99
Nov 27 06:14:59 vvd kernel: #14 0x1056558 at sys_write+0x78
Nov 27 06:14:59 vvd kernel: #15 0x155d6c4 at syscall+0x3d4
============================================================
Nov 27 06:35:17 vvd kernel: spin lock 0x1f11c80 (callout) held by 0x8f89700 (tid 100003) too long
Nov 27 06:35:17 vvd kernel: panic: spin lock held too long
Nov 27 06:35:17 vvd kernel: cpuid = 1
Nov 27 06:35:17 vvd kernel: time = 1574825580
Nov 27 06:35:17 vvd kernel: KDB: stack backtrace:
Nov 27 06:35:17 vvd kernel: #0 0x103c50e at kdb_backtrace+0x4e
Nov 27 06:35:17 vvd kernel: #1 0xff6001 at vpanic+0x121
Nov 27 06:35:17 vvd kernel: #2 0xff5ed4 at panic+0x14
Nov 27 06:35:17 vvd kernel: #3 0xfd8824 at _mtx_lock_indefinite_check+0x54
Nov 27 06:35:17 vvd kernel: #4 0xfd8405 at _mtx_lock_spin_cookie+0xc5
Nov 27 06:35:17 vvd kernel: #5 0x100e7cb at callout_lock+0x9b
Nov 27 06:35:17 vvd kernel: #6 0x100e28e at callout_reset_sbt_on+0x6e
Nov 27 06:35:17 vvd kernel: #7 0x1048c47 at sleepq_set_timeout_sbt+0xc7
Nov 27 06:35:17 vvd kernel: #8 0x10001e3 at _sleep+0x163
Nov 27 06:35:17 vvd kernel: #9 0x12f1744 at uma_reclaim_worker+0xd4
Nov 27 06:35:17 vvd kernel: #10 0xfbc8da at fork_exit+0x6a
Nov 27 06:35:17 vvd kernel: #11 0xffc033ca at PTDpde+0x43d2
============================================================
Nov 27 06:42:16 vvd kernel: spin lock 0x1f11c80 (callout) held by 0x8f89700 (tid 100003) too long
Nov 27 06:42:16 vvd kernel: panic: spin lock held too long
Nov 27 06:42:16 vvd kernel: cpuid = 1
Nov 27 06:42:16 vvd kernel: time = 1574826002
Nov 27 06:42:16 vvd kernel: KDB: stack backtrace:
Nov 27 06:42:16 vvd kernel: #0 0x103c50e at kdb_backtrace+0x4e
Nov 27 06:42:16 vvd kernel: #1 0xff6001 at vpanic+0x121
Nov 27 06:42:16 vvd kernel: #2 0xff5ed4 at panic+0x14
Nov 27 06:42:16 vvd kernel: #3 0xfd8824 at _mtx_lock_indefinite_check+0x54
Nov 27 06:42:16 vvd kernel: #4 0xfd8405 at _mtx_lock_spin_cookie+0xc5
Nov 27 06:42:16 vvd kernel: #5 0x100e7cb at callout_lock+0x9b
Nov 27 06:42:16 vvd kernel: #6 0x100e28e at callout_reset_sbt_on+0x6e
Nov 27 06:42:16 vvd kernel: #7 0x1048c47 at sleepq_set_timeout_sbt+0xc7
Nov 27 06:42:16 vvd kernel: #8 0x10001e3 at _sleep+0x163
Nov 27 06:42:16 vvd kernel: #9 0x10970b1 at buf_daemon+0xc1
Nov 27 06:42:16 vvd kernel: #10 0xfbc8da at fork_exit+0x6a
Nov 27 06:42:16 vvd kernel: #11 0xffc033ca at PTDpde+0x43d2
============================================================
Nov 27 06:58:04 vvd kernel: spin lock 0x1f11c80 (callout) held by 0x8f89700 (tid 100003) too long
Nov 27 06:58:04 vvd kernel: panic: spin lock held too long
Nov 27 06:58:04 vvd kernel: cpuid = 1
Nov 27 06:58:04 vvd kernel: time = 1574826900
Nov 27 06:58:04 vvd kernel: KDB: stack backtrace:
Nov 27 06:58:04 vvd kernel: #0 0x103c50e at kdb_backtrace+0x4e
Nov 27 06:58:04 vvd kernel: #1 0xff6001 at vpanic+0x121
Nov 27 06:58:04 vvd kernel: #2 0xff5ed4 at panic+0x14
Nov 27 06:58:04 vvd kernel: #3 0xfd8824 at _mtx_lock_indefinite_check+0x54
Nov 27 06:58:04 vvd kernel: #4 0xfd8405 at _mtx_lock_spin_cookie+0xc5
Nov 27 06:58:04 vvd kernel: #5 0x100e7cb at callout_lock+0x9b
Nov 27 06:58:04 vvd kernel: #6 0x100e28e at callout_reset_sbt_on+0x6e
Nov 27 06:58:04 vvd kernel: #7 0x1048c47 at sleepq_set_timeout_sbt+0xc7
Nov 27 06:58:04 vvd kernel: #8 0xf9a050 at _cv_timedwait_sbt+0x100
Nov 27 06:58:04 vvd kernel: #9 0x155db73 at syscall+0x883
Nov 27 06:58:04 vvd kernel: #10 0xffc033b7 at PTDpde+0x43bf
============================================================
Nov 27 07:33:46 vvd kernel: spin lock 0x21db240 (callout) held by 0x8f54700 (tid 100003) too long
Nov 27 07:33:46 vvd kernel: panic: spin lock held too long
Nov 27 07:33:46 vvd kernel: cpuid = 1
Nov 27 07:33:46 vvd kernel: time = 1574829142
Comment 46 Werner Lehmann 2019-11-28 08:26:48 UTC 
(In reply to VVD from comment #45)

I have always loaded through /boot/loader.conf, but for some time now I often had the issue that the boot process would hang right at the beginning (after the finishing of the countdown of the standard boot menu). I always had to push the shutdown button for a few seconds and push it again, and then usually everything went fine, SDDM/X included. As I am having overheating issues with that Laptop, I thought it had something to do with that. But reading your post, I put kld_list="nvidia" into /etc/rc.conf (I guess this is what you meant) to see how that works and after three reboots I did not have that hanging issue anymore, but I will have to observe this in the future. So thank you for your post. And no matter if loaded through /boot/loader.conf or /etc/rc.conf I have no issues with SDDM or X. Using GENERIC kernel. Maybe you have another issue. And oh, I just see that you upgraded to 12.0. Upgrade to 12.1, this is where firefox and Thunderbird started working for me.
Comment 47 VVD 2019-11-29 15:44:47 UTC 
(In reply to Werner Lehmann from comment #46)
Ofc it's 12.1.
Rebuilding all ports for 12.1 (some was from 12.0)...