Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

rec: Segfault on start on FreeBSD 10.3 i386(32bit) #4974

Closed
shonishe opened this issue Feb 5, 2017 · 13 comments
Closed

rec: Segfault on start on FreeBSD 10.3 i386(32bit) #4974

shonishe opened this issue Feb 5, 2017 · 13 comments
Labels
rec

Comments

@shonishe
Copy link

shonishe commented Feb 5, 2017 •
edited by zeha
Loading

Good day. I have segfault with default or changed config.
FreeBSD 10.3-RELEASE-p11 i386 (!!! - 32 bit)
pdns-recursor-4.0.4_1 from sources or package

I try to compile with and without SETROOT, LUA, LuaJit on variations, nothing to change in result.

By default, -O3, I dont know why, because my /etc/make.conf is blank.

 gdb --args /usr/local/sbin/pdns_recursor --daemon=no

GNU gdb 6.1.1 [FreeBSD]
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)...

(gdb) run
Starting program: /usr/local/sbin/pdns_recursor --daemon=no
Feb 05 23:36:20 PowerDNS Recursor 4.0.4 (C) 2001-2016 PowerDNS.COM BV
Feb 05 23:36:20 Using 32-bits mode. Built using clang 3.4.1 (tags/RELEASE_34/dot1-final 208032) on Feb  5 2017 23:34:31 by root@gw4
Feb 05 23:36:20 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
Feb 05 23:36:20 Reading random entropy from '/dev/urandom'
Feb 05 23:36:20 Enabling IPv6 transport for outgoing queries
Feb 05 23:36:20 Only allowing queries from: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fc00::/7, fe80::/10
Feb 05 23:36:20 Will not send queries to: 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fc00::/7, fe80::/10, 0.0.0.0/8, 192.0.0.0/24, 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 240.0.0.0/4, ::/96, ::ffff:0:0/96, 100::/64, 2001:db8::/32, 0.0.0.0, ::
Feb 05 23:36:20 PowerDNS Recursor itself will distribute queries over threads
Feb 05 23:36:20 Listening for UDP queries on 127.0.0.1:5388
Feb 05 23:36:20 Listening for TCP queries on 127.0.0.1:5388
Feb 05 23:36:20 Launching 3 threads
Feb 05 23:36:20 Done priming cache with root hints
Feb 05 23:36:20 Done priming cache with root hints

Program received signal SIGSEGV, Segmentation fault.
0x214f34e0 in ?? ()

(gdb) bt
#0  0x214f34e0 in ?? ()
#1  0x2284313c in ?? ()
#2  0x228081dc in ?? ()
#3  0x00030d40 in ?? ()
#4  0x010c0898 in ?? ()
#5  0x2284313c in ?? ()
#6  0x228081dc in ?? ()
#7  0x00000000 in ?? ()
@zeha
Copy link
Collaborator

zeha commented Feb 5, 2017

#0 0x214f34e0 in ?? ()

Please find debugging symbols; without them it's really hard to guess anything at all.

@Habbie
Copy link
Member

Habbie commented Feb 5, 2017

Possibly related: #4933, #4909

@zeha zeha changed the title Segfault on start Segfault on start on FreeBSD 10.3 i386(32bit) Feb 5, 2017
@zeha zeha added the rec label Feb 5, 2017
@Habbie
Copy link
Member

Habbie commented Feb 5, 2017

We'd like to understand why you are running i386 instead of amd64, can you explain?

@shonishe
Copy link
Author

shonishe commented Feb 5, 2017

@zeha, I cant compile this freebsd port with debug symbols. Its impossible. I can try with sources.

@shonishe
Copy link
Author

shonishe commented Feb 5, 2017

@Habbie Yes, youre right. i386 OS run on the amd64 platform. But why it can depend of? I think recursor can be check os kernel , not platform. (sorry, if my English pricks your ears)

@Habbie
Copy link
Member

Habbie commented Feb 5, 2017

I can deal with some broken English, do not worry :) But you did not answer -why- you are running i386.

@shonishe
Copy link
Author

shonishe commented Feb 5, 2017 •
edited
Loading

@Habbie I run i386 on the amd64 because we have some very old proprietary software on this server. we have no i386 hardware at all.

@Habbie
Copy link
Member

Habbie commented Mar 7, 2017

Closing due to silence. Please let us know if you have more details and we'll reopen.

@Habbie Habbie closed this as completed Mar 7, 2017
@RalfvdEnden
Copy link

Hi Peter. I have some details since a user mailed me with the exact same problem, only running on FreeBSD 12.1 i386 this time. He's running 4.2.1, but I can confirm it's also an issue with 4.3.0.

I built the recursor with debug symbols and running it through truss I get the following right before it dies:

connect(28,{ AF_UNIX "/var/run/logpriv" },106)   ERR#2 'No such file or directory'
connect(28,{ AF_UNIX "/var/run/log" },106)       ERR#2 'No such file or directory'
connect(28,{ AF_UNIX "/dev/log" },106)           ERR#2 'No such file or directory'
close(28)                                        = 0 (0x0)
sendto(-1,"<30>1 2020-05-18T21:13:20.787320"...,105,0,NULL,0) ERR#9 'Bad file descriptor'
kevent(27,{ 5,EVFILT_READ,EV_ADD,0,0,0x0 },1,0x0,0,0x0) = 0 (0x0)
mmap(0x0,233472,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593043456 (0x23592000)
getcontext(0x2353d300)                           = 0 (0x0)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593276928 (0x235cb000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593281024 (0x235cc000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593285120 (0x235cd000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593289216 (0x235ce000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593293312 (0x235cf000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593297408 (0x235d0000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593301504 (0x235d1000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593305600 (0x235d2000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593309696 (0x235d3000)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593313792 (0x235d4000)
mmap(0x0,233472,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 593317888 (0x235d5000)
getcontext(0x2353d600)                           = 0 (0x0)
kevent(25,0x0,0,{ },1024,{ 0.500000000 })        = 0 (0x0)
swapcontext(0x227f5000,0x227f5300)               = 0 (0x0)
SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0xffffffff
_umtx_op(0x220dec00,UMTX_OP_WAIT,0x18f57,0x0,0x0) ERR#4 'Interrupted system call'
<thread 101014 exited>
<thread 101366 exited>
<thread 102231 exited>
<thread 101745 exited>
process killed, signal = 11

If there's anything else I can do/supply to get this fixed just let me know.

@Habbie Habbie changed the title Segfault on start on FreeBSD 10.3 i386(32bit) rec: Segfault on start on FreeBSD 10.3 i386(32bit) May 18, 2020
@Habbie Habbie reopened this May 18, 2020
@Habbie
Copy link
Member

Habbie commented May 18, 2020

If there's anything else I can do/supply to get this fixed just let me know.

Assuming I somewhat know my way around FreeBSD, what do I do to get this crash?

@RvdE
Copy link
Contributor

RvdE commented May 18, 2020

Just starting it will do the trick.

@omoerbeek
Copy link
Member 

Thread 2 "pdns-r/distr" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100087 of process 921]
0x2188212c in jump_fcontext () from /usr/local/lib/libboost_context.so.1.72.0
(gdb) bt
#0  0x2188212c in jump_fcontext () from /usr/local/lib/libboost_context.so.1.72.0
#1  0x21fcb56c in ?? ()
#2  0x014eb966 in ?? ()
#3  0x014cc9a9 in ?? ()
#4  0x014f94a9 in ?? ()
#5  0x21bec88b in thread_start (curthread=0x21edb300)
    at /usr/src/lib/libthr/thread/thr_create.c:292
#6  0x00000000 in ?? ()

So the context switching seems broken, This could be a deep rabbit hole...

@Habbie
Copy link
Member

Habbie commented May 20, 2020

We decided a long time ago to not spend time on i386 for Linux users. We are making the same decision for other OSes here.

We would, of course, welcome a PR fixing this, but for now we're closing this, sorry!

@Habbie Habbie closed this as completed May 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
rec
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@zeha @Habbie @RvdE @shonishe @omoerbeek @RalfvdEnden