Re: head -r339076 based powerpc64 context: fatal kernel trap [ during /usr/tests/Kyuafile's sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ]
[Booting a debug kernel reported a lock order reversal that might be relevant. The problem repeated again: seems to always fail in my context. The backtrace is like the prior one, but for the debug kernel build being used this time.] On 2018-Oct-17, at 6:29 PM, Mark Millard wrote: > [I got another data storage interrupt failure, again > during kyaua showing: > > sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> > > but the backtrace looks different. See below.] > > On 2018-Oct-17, at 4:58 PM, Mark Millard wrote: > >> On a powerpc64 with builworld buildkernel built via >> devel/powerpc64-xtoolchain-gcc for head -r339076 >> (some source adjustments), and a system-cc-is-clang >> I attempted a: >> >> # kyua test -k /usr/tests/Kyuafile >> >> It got to: >> >> sys/netinet/reuseport_lb:basic_ipv4 -> failed: >> /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address >> already in use [0.014s] >> sys/netinet/reuseport_lb:basic_ipv6 -> failed: >> /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address >> already in use [0.014s] >> sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> >> >> and then the system crashed. I am re-running to >> see what happens. >> >> The context has a non-debug kernel (but with >> symbols). >> >> Hand transcribed from a picture . . . >> >> fatal kernel trap: >> >> exception = 0x300 (data storage interrupt) >> virtual address = 0xbfba8530 >> dsisr = 0x4200 >> srr0= 0x72b054 >> srr1= 0x90009032 >> current msr = 0x90009032 >> lr = 0x69948c >> curthread = 0xc00036f7f000 >> pid = 12798, comm = ifconfig >> >> [ thread pid 12798 tid 100312 ] >> Stopped at lock_init+0x78 stw r9,0x8(r3) >> db:0:kdb.enter.default> bt >> Tracing pid 12798 tid 100312 td 0xc00036f7f000 >> 0xe0004646e330: at 0xe0004646e36c >> 0xe0004646e360: at epair_modevent+0xf0 >> 0xe0004646e410: at module_register_init+0xe8 >> 0xe0004646e4a0: at linker_laod_module+0x6f8 > > Should have been: linker_load_module > >> 0xe0004646e580: at kern_kldload+0x150 >> 0xe0004646e5e0: at sys_kldload+0xb80 >> 0xe0004646e630: at trap+0xef4 >> 0xe0004646e790: at powerpc_interrupt+0x12c >> 0xe0004646e820: user sc trap by 0x81017fcf8 >> srr1 = 0x9000f032 >> r1 = 0x3fffcfe0 >> cr = 0x28022482 >> xer = 0x2000 >> ctr = 0x81017fcf0 >> r2 = 0x810336300 >> >> >> # uname -apKU >> FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct 15 >> 13:19:35 PDT 2018 >> markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG >> powerpc powerpc64 1200084 1200084 >> >> ports was at -r480180. >> > > Again failed during: > > sys/netinet/reuseport_lb:basic_ipv4 -> failed: > /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already > in use [0.013s] > sys/netinet/reuseport_lb:basic_ipv6 -> failed: > /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already > in use [0.013s] > sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> > > > The backtrace this time shows (hand transcribed): > > fatal kernel trap: > > exception = 0x300 (data storage interrupt) > virtual address = 0xc0008cab6530 > dsisr = 0x4200 > srr0= 0xe00046e5b228 > srr1= 0x90009032 > current msr = 0x90009032 > lr = 0xe00046e5b220 > curthread = 0xcd48e000 > pid = 9666, comm = jail > > [ thread pid 9666 tid 100185 ] > Stopped at vnet_epair_init+0x78: stdx r3,r29,r30 > db:0:kdb.enter.default> bt > Tracing pid 9666 tid 100185 td 0xcd48e000 > 0xe000470a1240: at vnet_sysinit+0x64 > 0xe000470a1270: at vnet_alloc+0xfc > 0xe000470a12d0: at kern_jail_set+0x1e30 > 0xe000470a15e0: at sys_jail_set+08c > 0xe000470a1630: at trap+0xef4 > 0xe000470a1790: at powerpc_interrupt+0x12c > 0xe000470a1820: user sc trap by 0x81016a888 > srr1 = 0x9000f032 > r1 = 0x3fffd090 > cr = 0x28002482 > xer = 0x2000 > ctr = 0x81016a880 > r2 = 0x810322300 > > I got a core.txt.0 this time. it reported: > > . . . > epair3a: Ethernet address: 02:60:27:70:4b:0a > epair3b: Ethernet address: 02:60:27:70:4b:0b > epair3a: link state changed to UP > epair3b: link state changed to UP > > fatal kernel trap: > > exception = 0x300 (data storage interrupt) > virtual address = 0xc0008cab6530 > dsisr = 0x4200 > srr0= 0xe00046e5b228 (0xe00046e5b228) > srr1= 0x90009032 > current msr = 0x90009032 > lr = 0xe00046e5b220 (0xe00046e5b220) > curthread = 0xcd48e000 > pid = 9666, comm = jail > > epair3a: Ethernet address: 02:60:27:70:4b:0a epair3b: Ethernet address: 02:60:27:70:4b:0b epair3a: link state
Re: head -r339076 based powerpc64 context: fatal kernel trap [ during /usr/tests/Kyuafile's sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ]
[I got another data storage interrupt failure, again during kyaua showing: sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> but the backtrace looks different. See below.] On 2018-Oct-17, at 4:58 PM, Mark Millard wrote: > On a powerpc64 with builworld buildkernel built via > devel/powerpc64-xtoolchain-gcc for head -r339076 > (some source adjustments), and a system-cc-is-clang > I attempted a: > > # kyua test -k /usr/tests/Kyuafile > > It got to: > > sys/netinet/reuseport_lb:basic_ipv4 -> failed: > /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already > in use [0.014s] > sys/netinet/reuseport_lb:basic_ipv6 -> failed: > /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already > in use [0.014s] > sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> > > and then the system crashed. I am re-running to > see what happens. > > The context has a non-debug kernel (but with > symbols). > > Hand transcribed from a picture . . . > > fatal kernel trap: > > exception = 0x300 (data storage interrupt) > virtual address = 0xbfba8530 > dsisr = 0x4200 > srr0= 0x72b054 > srr1= 0x90009032 > current msr = 0x90009032 > lr = 0x69948c > curthread = 0xc00036f7f000 > pid = 12798, comm = ifconfig > > [ thread pid 12798 tid 100312 ] > Stopped at lock_init+0x78 stw r9,0x8(r3) > db:0:kdb.enter.default> bt > Tracing pid 12798 tid 100312 td 0xc00036f7f000 > 0xe0004646e330: at 0xe0004646e36c > 0xe0004646e360: at epair_modevent+0xf0 > 0xe0004646e410: at module_register_init+0xe8 > 0xe0004646e4a0: at linker_laod_module+0x6f8 Should have been: linker_load_module > 0xe0004646e580: at kern_kldload+0x150 > 0xe0004646e5e0: at sys_kldload+0xb80 > 0xe0004646e630: at trap+0xef4 > 0xe0004646e790: at powerpc_interrupt+0x12c > 0xe0004646e820: user sc trap by 0x81017fcf8 > srr1 = 0x9000f032 > r1 = 0x3fffcfe0 > cr = 0x28022482 > xer = 0x2000 > ctr = 0x81017fcf0 > r2 = 0x810336300 > > > # uname -apKU > FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct 15 > 13:19:35 PDT 2018 > markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG > powerpc powerpc64 1200084 1200084 > > ports was at -r480180. > Again failed during: sys/netinet/reuseport_lb:basic_ipv4 -> failed: /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already in use [0.013s] sys/netinet/reuseport_lb:basic_ipv6 -> failed: /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already in use [0.013s] sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> The backtrace this time shows (hand transcribed): fatal kernel trap: exception = 0x300 (data storage interrupt) virtual address = 0xc0008cab6530 dsisr = 0x4200 srr0= 0xe00046e5b228 srr1= 0x90009032 current msr = 0x90009032 lr = 0xe00046e5b220 curthread = 0xcd48e000 pid = 9666, comm = jail [ thread pid 9666 tid 100185 ] Stopped at vnet_epair_init+0x78: stdx r3,r29,r30 db:0:kdb.enter.default> bt Tracing pid 9666 tid 100185 td 0xcd48e000 0xe000470a1240: at vnet_sysinit+0x64 0xe000470a1270: at vnet_alloc+0xfc 0xe000470a12d0: at kern_jail_set+0x1e30 0xe000470a15e0: at sys_jail_set+08c 0xe000470a1630: at trap+0xef4 0xe000470a1790: at powerpc_interrupt+0x12c 0xe000470a1820: user sc trap by 0x81016a888 srr1 = 0x9000f032 r1 = 0x3fffd090 cr = 0x28002482 xer = 0x2000 ctr = 0x81016a880 r2 = 0x810322300 I got a core.txt.0 this time. it reported: . . . epair3a: Ethernet address: 02:60:27:70:4b:0a epair3b: Ethernet address: 02:60:27:70:4b:0b epair3a: link state changed to UP epair3b: link state changed to UP fatal kernel trap: exception = 0x300 (data storage interrupt) virtual address = 0xc0008cab6530 dsisr = 0x4200 srr0= 0xe00046e5b228 (0xe00046e5b228) srr1= 0x90009032 current msr = 0x90009032 lr = 0xe00046e5b220 (0xe00046e5b220) curthread = 0xcd48e000 pid = 9666, comm = jail === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
head -r339076 based powerpc64 context: fatal kernel trap Stopped at lock_init+0x78 stw r9,0x8(r3)
On a powerpc64 with builworld buildkernel built via devel/powerpc64-xtoolchain-gcc for head -r339076 (some source adjustments), and a system-cc-is-clang I attempted a: # kyua test -k /usr/tests/Kyuafile It got to: sys/netinet/reuseport_lb:basic_ipv4 -> failed: /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already in use [0.014s] sys/netinet/reuseport_lb:basic_ipv6 -> failed: /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already in use [0.014s] sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> and then the system crashed. I am re-running to see what happens. The context has a non-debug kernel (but with symbols). Hand transcribed from a picture . . . fatal kernel trap: exception = 0x300 (data storage interrupt) virtual address = 0xbfba8530 dsisr = 0x4200 srr0= 0x72b054 srr1= 0x90009032 current msr = 0x90009032 lr = 0x69948c curthread = 0xc00036f7f000 pid = 12798, comm = ifconfig [ thread pid 12798 tid 100312 ] Stopped at lock_init+0x78 stw r9,0x8(r3) db:0:kdb.enter.default> bt Tracing pid 12798 tid 100312 td 0xc00036f7f000 0xe0004646e330: at 0xe0004646e36c 0xe0004646e360: at epair_modevent+0xf0 0xe0004646e410: at module_register_init+0xe8 0xe0004646e4a0: at linker_laod_module+0x6f8 0xe0004646e580: at kern_kldload+0x150 0xe0004646e5e0: at sys_kldload+0xb80 0xe0004646e630: at trap+0xef4 0xe0004646e790: at powerpc_interrupt+0x12c 0xe0004646e820: user sc trap by 0x81017fcf8 srr1 = 0x9000f032 r1 = 0x3fffcfe0 cr = 0x28022482 xer = 0x2000 ctr = 0x81017fcf0 r2 = 0x810336300 # uname -apKU FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct 15 13:19:35 PDT 2018 markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1200084 1200084 ports was at -r480180. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
contigmalloc uses up all free memory.
Hello,
I have encountered an issue with a kernel application that I have written,
the application allocates and deallocates contiguous memory using
contigmalloc() and contigfree().
The application will fail after a period of time because there is not enough
free contiguous memory left.
There could be an issue with the freeing of memory when using the contigfree()
function.
I have attached a simplified version of the application.
The resulting kernel module just allocates contiguous memory and then frees the
memory using contigfree();
This allocation is done in a loop and the attached src code triggers the issue.
After a period of time when running the application multiple times, the kernel
reports
that there is no available memory and fails with allocation.
I can see that the amount of free memory is decreasing in correlation to how
many
times I run the application by using DDB and printing out freepages using "show
freepages"
I run the application in a loop using a shell script where I kldload then
kldunload multiple times (script runs up to 100)
The application can take 20 to over 60 minutes to trigger the issue and run out
of memory but can take longer also.
I am running the application on ->
FreeBSD 12.0-ALPHA9 also tested on 11.2
VM with 2 Gb of ram.
Allocating one cpu core.
Running on an Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GH using Ubuntu 16.04 host.
I have attached the test kernel application and a Makefile.
Thanks,
Ciunas.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
#include
#include
#include
#include
#include
#include
#define DEV_MEM "test_mem"
MALLOC_DECLARE(TEST_MEM);
MALLOC_DEFINE(TEST_MEM, "test_mem", "test_mem driver");
/* Test application to allocate contiguous memory then free it */
static int test_application()
{
int i = 0;
int array[10] = {2097152, 1024, 2101248, 1024, 2097152, 2101248,
2101248, 2097152, 2101248, 1024};
int array1[10] = {1024, 2101248, 2097152, 2101248, 2101248, 2097152,
1024, 2101248, 1024, 2097152};
void *mem_blocks[10];
for (i = 0; i < 10; i++)
{
mem_blocks[i] = contigmalloc(array[i], TEST_MEM, 0, 0, ~0, PAGE_SIZE,
0);
if (!mem_blocks[i])
{
printf("%s:%d Unable to allocate contiguous memory slab \n",
__func__,
__LINE__);
return -1;
}
}
for (i = 0; i < 10; i++)
contigfree(mem_blocks[i], array[i], TEST_MEM);
for (i = 0; i < 10; i++)
{
mem_blocks[i] = contigmalloc(array1[i], TEST_MEM, 0, 0, ~0, PAGE_SIZE,
0);
if (!mem_blocks[i])
{
printf("%s:%d Unable to allocate contiguous memory slab \n",
__func__,
__LINE__);
return -1;
}
}
for (i = 0; i < 10; i++)
contigfree(mem_blocks[i], array1[i], TEST_MEM);
return 0;
}
static int mem_modevent(module_t mod __unused,
int type,
void *data __unused)
{
switch (type)
{
case MOD_LOAD:
test_application();
return (0);
case MOD_UNLOAD:
return (0);
default:
return (EOPNOTSUPP);
}
}
DEV_MODULE(test_mem, mem_modevent, NULL);
MODULE_VERSION(test_mem, 1);
Makefile
Description: Makefile
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
Compiling ftp/curl from source and installing it has fixed the issue. Thank you both for the help/suggestions! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
I think this just depends on when packages were built in relation to the upgrade of openssl on current. I have just got over this problem by rebuilding and installing the ftp/curl port (different problem here, curl was failing but referred to older version of libssl and libcrypto - which I didn't have a snapshot build). I also rebuilt 'pkg' to get over the same problem. Hopefully package building will catch up with this fairly quickly. My problem was on arm64 so probably a lower priority for getting ports back on track than amd64. Cheers, Brian On 17/10/18 7:15 pm, Brennan Vincent wrote: > Hi Kubilay (or do you prefer "koobs"?). Thanks for the response. > > To answer your questions: > * I am using latest packages > * My /etc/make.conf was empty when I built the system, and now just has > `WITH_DEBUG=yes`. > > # uname -a > FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 > 03:28:51 UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > # ldd /usr/local/bin/curl > /usr/local/bin/curl: > libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000) > libz.so.6 => /lib/libz.so.6 (0x8002e7000) > libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000) > libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000) > libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000) > libthr.so.3 => /lib/libthr.so.3 (0x8003b1000) > libc.so.7 => /lib/libc.so.7 (0x8003dc000) > libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000) > libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000) > libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000) > libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000) > libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000) > libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000) > libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000) > libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000) > libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000) > libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000) > libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000) > libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 > (0x800f52000) > # ldd /usr/local/lib/libcurl.so.4 > /usr/local/lib/libcurl.so.4: > libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000) > libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000) > libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000) > libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0) > libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000) > libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000) > libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000) > libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000) > libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e) > libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000) > libz.so.6 => /lib/libz.so.6 (0x801189000) > libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000) > libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000) > libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000) > libthr.so.3 => /lib/libthr.so.3 (0x801253000) > libc.so.7 => /lib/libc.so.7 (0x800248000) > libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000) > libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 > (0x80156b000) > > (aha - libcurl depends on .8 , and the curl binary depends on .9) > > From a cursory glance at the source tree, it seems libcrypto is part of > openssl, is this right? It seems the openssl version is in flux right now, > that might explain things... > > Cheers, > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
No, I've never run `delete-old` and `delete-old-lib` while upgrading. I can try upgrading again tomorrow and running those. But if my installation of curl is for whatever reason depending on libcrypto.so.8 and that command deletes it, won't that just cause curl to stop working? (I tried manually moving libcrypto.so.8 to libcrypto.so.8.bak and as expected, now `git clone` failed because the .so couldn't be found.) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
oh, actually I should point out that /usr/local/lib/libcurl.so.4 depends on *both* /lib/libcrypto.so.8 and /lib/libcrypto.so.9 , from the output I showed in my last email. I'm not sure how to get the PORTVERSION and PORTREVISION... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
On 17/10/2018 7:14 pm, Brennan Vincent wrote: Hi Kubilay (or do you prefer "koobs"?). Thanks for the response. To answer your questions: * I am using latest packages * My /etc/make.conf was empty when I built the system, and now just has `WITH_DEBUG=yes`. # uname -a FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 03:28:51 UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 # ldd /usr/local/bin/curl /usr/local/bin/curl: libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000) libz.so.6 => /lib/libz.so.6 (0x8002e7000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000) libthr.so.3 => /lib/libthr.so.3 (0x8003b1000) libc.so.7 => /lib/libc.so.7 (0x8003dc000) libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000) libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000) libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000) libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000) libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000) libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x800f52000) # ldd /usr/local/lib/libcurl.so.4 /usr/local/lib/libcurl.so.4: libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000) libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000) libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e) libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000) libz.so.6 => /lib/libz.so.6 (0x801189000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000) libthr.so.3 => /lib/libthr.so.3 (0x801253000) libc.so.7 => /lib/libc.so.7 (0x800248000) libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000) libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x80156b000) (aha - libcurl depends on .8 , and the curl binary depends on .9) From a cursory glance at the source tree, it seems libcrypto is part of openssl, is this right? It seems the openssl version is in flux right now, that might explain things... OpenSSL 1.1.1 import happened 7 days ago [1], which may partially explain the cause. Having two versions of the shared libraries in base is unexpected though, unless its intentional for some reason, or I'm missing/forgetting something. Do you run the delete-old / delete-old-lib targets during your upgrades? [1] https://svnweb.freebsd.org/changeset/base/339270 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
Hi Kubilay (or do you prefer "koobs"?). Thanks for the response. To answer your questions: * I am using latest packages * My /etc/make.conf was empty when I built the system, and now just has `WITH_DEBUG=yes`. # uname -a FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 03:28:51 UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 # ldd /usr/local/bin/curl /usr/local/bin/curl: libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000) libz.so.6 => /lib/libz.so.6 (0x8002e7000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000) libthr.so.3 => /lib/libthr.so.3 (0x8003b1000) libc.so.7 => /lib/libc.so.7 (0x8003dc000) libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000) libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000) libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000) libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000) libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000) libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x800f52000) # ldd /usr/local/lib/libcurl.so.4 /usr/local/lib/libcurl.so.4: libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000) libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000) libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000) libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000) libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000) libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000) libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e) libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000) libz.so.6 => /lib/libz.so.6 (0x801189000) libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000) libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000) libthr.so.3 => /lib/libthr.so.3 (0x801253000) libc.so.7 => /lib/libc.so.7 (0x800248000) libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000) libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 (0x80156b000) (aha - libcurl depends on .8 , and the curl binary depends on .9) >From a cursory glance at the source tree, it seems libcrypto is part of >openssl, is this right? It seems the openssl version is in flux right now, >that might explain things... Cheers, ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Git segfaulting in libcrypto.so when trying to clone.
On 17/10/2018 6:34 pm, Brennan Vincent wrote: This also happens in the stock `git` installed from `pkg`, but I have installed it also from `/usr/ports` so I could enable debug symbols and get a proper stacktrace. When cloning any https repo (or at least the ones from github that I tried), git segfaults in `git-remote-https`, and the core dump shows the following stack trace: * frame #0: 0x00080081f36c libc.so.7`strcmp at strcmp.S:46 frame #1: 0x000800d04f1d libcrypto.so.8`lh_insert [inlined] getrn(lh=, data=0x0008013aba20) at lhash.c:434 frame #2: 0x000800d04ebb libcrypto.so.8`lh_insert(lh=0x000801359480, data=0x0008013aba20) at lhash.c:207 frame #3: 0x000800d0f05e libcrypto.so.8`OBJ_NAME_add(name=0x, type=, data="m\x04") at o_names.c:202 frame #4: 0x00080120ab8d libcrypto.so.9`openssl_add_all_ciphers_int at c_allc.c:83 frame #5: 0x00080120a4b9 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ [inlined] ossl_init_add_all_ciphers at init.c:216 frame #6: 0x00080120a4b4 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205 frame #7: 0x00080064de28 libthr.so.3`_pthread_once(once_control=0x00080128a3b0, init_routine=(libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205)) at thr_once.c:97 frame #8: 0x000801209b69 libcrypto.so.9`CRYPTO_THREAD_run_once(once=, init=) at threads_pthread.c:113 frame #9: 0x000801209f67 libcrypto.so.9`OPENSSL_init_crypto(opts=2097228, settings=0x) at init.c:611 frame #10: 0x00080052982d libssl.so.9`OPENSSL_init_ssl(opts=2097152, settings=) at ssl_init.c:197 frame #11: 0x000800525cb4 libssl.so.9`SSL_CTX_new(meth=0x000800b0d1d0) at ssl_lib.c:2883 frame #12: 0x0008004a4a92 libcurl.so.4`___lldb_unnamed_symbol655$$libcurl.so.4 + 2722 frame #13: 0x0008004a935f libcurl.so.4`___lldb_unnamed_symbol671$$libcurl.so.4 + 271 frame #14: 0x00080045b455 libcurl.so.4`___lldb_unnamed_symbol59$$libcurl.so.4 + 405 frame #15: 0x0008004661ca libcurl.so.4`___lldb_unnamed_symbol136$$libcurl.so.4 + 154 frame #16: 0x00080047c436 libcurl.so.4`___lldb_unnamed_symbol259$$libcurl.so.4 + 934 frame #17: 0x00080047bf0e libcurl.so.4`curl_multi_perform + 222 frame #18: 0x0026a519 git-remote-https`step_active_slots at http.c:1293 frame #19: 0x0026a596 git-remote-https`run_active_slot(slot=0x0008012fa4c0) at http.c:1314 frame #20: 0x0026a9f8 git-remote-https`run_one_slot(slot=0x0008012fa4c0, results=0x7fffe0f8) at http.c:1509 frame #21: 0x0026dc6a git-remote-https`http_request(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;, result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1793 frame #22: 0x0026ac5b git-remote-https`http_request_reauth(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;, result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1869 frame #23: 0x0026ac1c git-remote-https`http_get_strbuf(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;, result=0x7fffe298, options=0x7fffe1f0) at http.c:1910 frame #24: 0x00264fbd git-remote-https`discover_refs(service="", for_push=0) at remote-curl.c:385 frame #25: 0x00263ca2 git-remote-https`get_refs(for_push=0) at remote-curl.c:465 frame #26: 0x0026361a git-remote-https`cmd_main(argc=3, argv=0x7fffe470) at remote-curl.c:1369 frame #27: 0x002707d7 git-remote-https`main(argc=3, argv=0x7fffe470) at common-main.c:45 frame #28: 0x0026311b git-remote-https`_start(ap=, cleanup=) at crt1.c:76 Hi Brennan, git gets its HTTP/HTTPS/etc support via curl, so it's likely an issue there. Note in particular that we jump from `libcrypto.so.9` to `libcrypto.so.8`... that seems wrong to me, but I'm not an expert. There have been many instances in the past where software (from ports/packages) ends up linked against *both* OpenSSL from base and OpenSSL from ports, due to various issues. This is probably a similar issue. The same problem can occur for anything that base provides, that can also be provided by ports, gssapi, ncurses, readline, among others come to mind. `/lib/libcrypto.so.8` and `/lib/libcrypto.so.9` both exist for me. If both exist in base, that's interesting (and probably a problem). I only have libcrypto.so.8 on a recent (month old) CURRENT build. The openssl port (which curl can use) provides libcrypto.so.9 (in /usr/local/lib) I can't reproduce this on a pristine install of 12.0-ALPHA10. Some more system information might prove useful: - FreeBSD version issue is reproducible on (uname -a) - Output of ldd /usr/local/bin/curl - Using quarterly or latest packages? - What
Git segfaulting in libcrypto.so when trying to clone.
This also happens in the stock `git` installed from `pkg`, but I have installed it also from `/usr/ports` so I could enable debug symbols and get a proper stacktrace. When cloning any https repo (or at least the ones from github that I tried), git segfaults in `git-remote-https`, and the core dump shows the following stack trace: * frame #0: 0x00080081f36c libc.so.7`strcmp at strcmp.S:46 frame #1: 0x000800d04f1d libcrypto.so.8`lh_insert [inlined] getrn(lh=, data=0x0008013aba20) at lhash.c:434 frame #2: 0x000800d04ebb libcrypto.so.8`lh_insert(lh=0x000801359480, data=0x0008013aba20) at lhash.c:207 frame #3: 0x000800d0f05e libcrypto.so.8`OBJ_NAME_add(name=0x, type=, data="m\x04") at o_names.c:202 frame #4: 0x00080120ab8d libcrypto.so.9`openssl_add_all_ciphers_int at c_allc.c:83 frame #5: 0x00080120a4b9 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ [inlined] ossl_init_add_all_ciphers at init.c:216 frame #6: 0x00080120a4b4 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205 frame #7: 0x00080064de28 libthr.so.3`_pthread_once(once_control=0x00080128a3b0, init_routine=(libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205)) at thr_once.c:97 frame #8: 0x000801209b69 libcrypto.so.9`CRYPTO_THREAD_run_once(once=, init=) at threads_pthread.c:113 frame #9: 0x000801209f67 libcrypto.so.9`OPENSSL_init_crypto(opts=2097228, settings=0x) at init.c:611 frame #10: 0x00080052982d libssl.so.9`OPENSSL_init_ssl(opts=2097152, settings=) at ssl_init.c:197 frame #11: 0x000800525cb4 libssl.so.9`SSL_CTX_new(meth=0x000800b0d1d0) at ssl_lib.c:2883 frame #12: 0x0008004a4a92 libcurl.so.4`___lldb_unnamed_symbol655$$libcurl.so.4 + 2722 frame #13: 0x0008004a935f libcurl.so.4`___lldb_unnamed_symbol671$$libcurl.so.4 + 271 frame #14: 0x00080045b455 libcurl.so.4`___lldb_unnamed_symbol59$$libcurl.so.4 + 405 frame #15: 0x0008004661ca libcurl.so.4`___lldb_unnamed_symbol136$$libcurl.so.4 + 154 frame #16: 0x00080047c436 libcurl.so.4`___lldb_unnamed_symbol259$$libcurl.so.4 + 934 frame #17: 0x00080047bf0e libcurl.so.4`curl_multi_perform + 222 frame #18: 0x0026a519 git-remote-https`step_active_slots at http.c:1293 frame #19: 0x0026a596 git-remote-https`run_active_slot(slot=0x0008012fa4c0) at http.c:1314 frame #20: 0x0026a9f8 git-remote-https`run_one_slot(slot=0x0008012fa4c0, results=0x7fffe0f8) at http.c:1509 frame #21: 0x0026dc6a git-remote-https`http_request(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;, result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1793 frame #22: 0x0026ac5b git-remote-https`http_request_reauth(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;, result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1869 frame #23: 0x0026ac1c git-remote-https`http_get_strbuf(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;, result=0x7fffe298, options=0x7fffe1f0) at http.c:1910 frame #24: 0x00264fbd git-remote-https`discover_refs(service="", for_push=0) at remote-curl.c:385 frame #25: 0x00263ca2 git-remote-https`get_refs(for_push=0) at remote-curl.c:465 frame #26: 0x0026361a git-remote-https`cmd_main(argc=3, argv=0x7fffe470) at remote-curl.c:1369 frame #27: 0x002707d7 git-remote-https`main(argc=3, argv=0x7fffe470) at common-main.c:45 frame #28: 0x0026311b git-remote-https`_start(ap=, cleanup=) at crt1.c:76 Note in particular that we jump from `libcrypto.so.9` to `libcrypto.so.8`... that seems wrong to me, but I'm not an expert. `/lib/libcrypto.so.8` and `/lib/libcrypto.so.9` both exist for me. I can't reproduce this on a pristine install of 12.0-ALPHA10. Does anyone have any ideas? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fuser does not list id of processes that have a file
> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/fuser.c
> index b4225328fc1f..17d06f1c5b13 100644
> --- a/usr.bin/fstat/fuser.c
> +++ b/usr.bin/fstat/fuser.c
> @@ -92,7 +92,7 @@ struct consumer {
>STAILQ_ENTRY(consumer) next;
> };
> struct reqfile {
> - uint32_tfsid;
> + uint64_tfsid;
>uint64_tfileid;
>const char *name;
>STAILQ_HEAD(, consumer) consumers;
The above patch does not resolve the problem for me.
Regards.
On Tue, Oct 16, 2018 at 5:17 PM Ed Schouten wrote:
> Hi there,
>
> Op di 16 okt. 2018 om 15:05 schreef Mateusz Guzik :
> > struct reqfile {
> > - uint32_tfsid;
> > + uint64_tfsid;
> > uint64_tfileid;
>
> Considering that these are based on sb.st_{ino,dev}, maybe better to
> use the occasion to switch these fields to dev_t and ino_t?
>
> --
> Ed Schouten
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
