Bug 266909 - irc/anope: update to 2.0.13, fixes COREDUMP patch, Request MAINTAINER'ship
Summary: irc/anope: update to 2.0.13, fixes COREDUMP patch, Request MAINTAINER'ship
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Mikael Urankar
URL:
Keywords: needs-patch
Depends on:
Blocks:
 
Reported: 2022-10-08 22:06 UTC by Rafael Grether
Modified: 2023-07-18 12:16 UTC (History)
4 users (show)

See Also:
devnull: maintainer-feedback? (egypcio)


Attachments
Anope to 2.0.13, coredump fixes, Request MAINTAINER'ship (3.39 KB, patch)
2023-06-02 18:47 UTC, Rafael Grether
devnull: maintainer-approval?
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Grether 2022-10-08 22:06:11 UTC
Hi,

irc/anope build perfectly on FreeBSD 13.1, but occurs coredump on run:

$ ./services 
Anope 2.0.11, build #1, compiled 18:07:11 Oct  8 2022
Segmentation fault (core dumped)

On FreeBSD 13.0 runs fine.

Initially I thought it might be some sysctl configuration, like wˆx...
But if I build irc/anope on FreeBSD 13.0, copy the binaries and move the binaries to FreeBSD 13.1, anope runs fine.

The problem only occurs when anope is BUILDED on FreeBSD 13.1.

I don't know if it would be something specific to anope. Maybe it's a clang problem, I don't know.

I tested on a fresh FreeBSD install, FreeBSD 13.0 and FreeBSD 13.1.

Thanks
Comment 1 Vinícius Zavam freebsd_committer freebsd_triage 2022-12-30 13:10:36 UTC
(In reply to Rafael Grether from comment #0)

ACK; I also confirm the issue from my side. thanks for reporting that! very appreciated.

I shall take a little more time and also jump into reproducing it on top of HEAD (14.0-CURRENT), just in case.

PS: port was updated to 2.0.12 -- https://cgit.freebsd.org/ports/commit/?id=a327f61c11a497e8f90a513dba837c84329b3b2f
Comment 2 Rafael Grether 2022-12-30 18:02:13 UTC
Thanks for your reply Vinícius.

I didn't investigate deep this issue cause I don't have that much experience, but I will try to do this as soon as possible to help, maybe running a backtrace and inspect system calls.
Comment 3 pyili 2023-04-11 11:04:12 UTC
Just letting everyone know who also searches for a solution: 
Compiling using gcc seems to work fine and the resulting binary does not quit with a segfault.
So installing gcc and using "export CXX=g++" when building helps. Although that does not fix the port, maybe it helps tracing the problem, as we now know, building on FreeBSD prior to 13.1 and using GCC on 13.1 and 13.2 is not affected.
Comment 4 Rafael Grether 2023-05-03 22:43:13 UTC
Thanks pyili.

I will do more tests now.
I didn't got any satisfactory result tracing system calls.
It occurs after loading conf/modules.conf

SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x20

This error generally indicates that the error occurred while attempting to access memory that was not properly mapped.

I will try to debug using gdb.
Comment 5 Rafael Grether 2023-05-04 02:51:46 UTC
Using GDB, it breaks at int i = fork(); (init.cpp:462). After this, coredump.
Program received signal SIGUSR2, User defined signal 2.

I don't know what happens. After I will try to compare with anope builded with GCC.

bt full, I got:

#2  0x000000000037e628 in Anope::Init (ac=1, av=0x7fffffffe990) at /home/irc-gigachat/anope-2.0.12/src/init.cpp:468
        mask = {__bits = {0, 0, 0, 0}}
        sa = {__sigaction_u = {__sa_handler = 0x380a30 <parent_signal_handler(int)>, __sa_sigaction = 0x380a30 <parent_signal_handler(int)>}, sa_flags = 0, 
          sa_mask = {__bits = {0, 0, 0, 0}}}
        old_sigusr2 = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {4294901503, 4294967295, 4294967295, 
              4294967295}}}
        old_sigchld = {__sigaction_u = {__sa_handler = 0x0, __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}}
        i = 10871
        arg = {_string = {static __short_mask = 1, static __long_mask = 1, 
            __r_ = {<std::__1::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false>> = {
                __value_ = {{__l = {__cap_ = 458752, __size_ = 34366353458, __data_ = 0x7fe0f05 <error: Cannot access memory at address 0x7fe0f05>}, __s = {{
                        __size_ = 0 '\000', __lx = 0 '\000'}, __data_ = "\000\a\000\000\000\000\0002\360d\000\b\000\000\000\005\017\376\a\000\000\000"}, __r = {
                      __words = {458752, 34366353458, 
                        134090501}}}}}, <std::__1::__compressed_pair_elem<std::__1::allocator<char>, 1, true>> = {<std::__1::allocator<char>> = {<std::__1::__non_trivial_if<true, std::__1::allocator<char> >> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, static npos = 18446744073709551615}, 
          static npos = 18446744073709551615}
        ex = <error reading variable: Cannot access memory at address 0x0>
        block = 0x0
        protocol = 0x0

--Type <RET> for more, q to quit, c to continue without paging--

        MOD_RESULT = EVENT_STOP
#3  0x000000000038d4c5 in main (ac=1, av=0x7fffffffe990, envp=0x7fffffffe9a0) at /home/irc-gigachat/anope-2.0.12/src/main.cpp:140
        n = 31
        ex = @0x7fffffffe9a0: {<std::exception> = {_vptr$exception = 0x7fffffffed05}, err = {_string = {static __short_mask = 1, static __long_mask = 1, 
              __r_ = {<std::__1::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false>> = {__value_ = {{__l = {__cap_ = 140737488350481, __size_ = 140737488350490, __data_ = 0x7fffffffed2a "HOME=/home/irc-gigachat"}, __s = {{__size_ = 17 '\021', 
                          __lx = 17 '\021'}, __data_ = "\355\377\377\377\177\000\000\032\355\377\377\377\177\000\000*\355\377\377\377\177\000"}, __r = {
                        __words = {140737488350481, 140737488350490, 
                          140737488350506}}}}}, <std::__1::__compressed_pair_elem<std::__1::allocator<char>, 1, true>> = {<std::__1::allocator<char>> = {<std::__1::__non_trivial_if<true, std::__1::allocator<char> >> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, 
              static npos = 18446744073709551615}, static npos = 18446744073709551615}, source = {_string = {static __short_mask = 1, static __long_mask = 1, 
              __r_ = {<std::__1::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false>> = {__value_ = {{__l = {__cap_ = 140737488350530, __size_ = 140737488350548, __data_ = 0x7fffffffed76 "LOGNAME=ec2-user"}, __s = {{__size_ = 66 'B', __lx = 66 'B'}, 
                        __data_ = "\355\377\377\377\177\000\000T\355\377\377\377\177\000\000v\355\377\377\377\177\000"}, __r = {__words = {140737488350530, 
                          140737488350548, 
                          140737488350582}}}}}, <std::__1::__compressed_pair_elem<std::__1::allocator<char>, 1, true>> = {<std::__1::allocator<char>> = {<std::__1::__non_trivial_if<true, std::__1::allocator<char> >> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, 
              static npos = 18446744073709551615}, static npos = 18446744073709551615}}
        ex = <error reading variable: Cannot access memory at address 0x0>
        last_check = 0
        updateTimer = {<Timer> = {_vptr$Timer = 0x0, owner = 0x80062edc8, settime = 0, trigger = 0, secs = 0, repeat = false}, <No data fields>}
        expireTimer = {<Timer> = {_vptr$Timer = 0x0, owner = 0x0, settime = 34364273673, trigger = 140737488348520, secs = 34366344292, 
            repeat = 203}, <No data fields>}
Comment 6 Vinícius Zavam freebsd_committer freebsd_triage 2023-05-21 16:51:16 UTC
(In reply to pyili from comment #3)

thank you for sharing that! unfortunately I could not get any further on implementing a proper solution to us all here.

I will then drop maintainership of the port to allow a more wider attention.

sometimes it's just like that; I decided to drop it instead of producing bad code to patch it "whatever".
Comment 7 Rafael Grether 2023-05-26 17:49:37 UTC
@VINICIUS

Thanks for investigating this.
According @SadieCat (from anope), this problem is related to "-fno-delete-null-pointer-checks" flags that exists in GCC but doesnt work properly in CLANG ships with FreeBSD >= 13.1

@SadieCat tried to generate a patch, but without success:
https://github.com/SadieCat/anope/commit/b7abfe5eca076c29a0d49a411320612264093bdf.patch

I understand if you decide to drop maintainership, and despite my limited knowledge, I'm trying to do my best to keep anope working on FreeBSD (whether via ports or direct from upstream).
Comment 8 Rafael Grether 2023-05-26 17:52:30 UTC
@VINICIUS,

What if we wrap the FreeBSD core, since it's a clang thing?
Comment 9 Rafael Grether 2023-05-29 02:16:42 UTC
@MAINTAINER

Good news!

Don't drop maintainership. The patch is coming!!
Comment 10 adam 2023-06-02 02:54:21 UTC
Hi, I am the upstream maintainer of Anope. We've released version 2.0.13 which fixes this issue. I've removed the dependency on -fno-delete-null-pointer-checks so it works on either clang or gcc.
Comment 11 Rafael Grether 2023-06-02 18:47:46 UTC
Created attachment 242561 [details]
Anope to 2.0.13, coredump fixes, Request MAINTAINER'ship

@COMMITER

Please update anope to version 2.0.13.

This update fixes crash (coredump) on CLANG when trying to call methods on a null pointer.

Without maintainer, please commit these changes and change the maintainer.

QA tests pass.

Anope was builded in a poudriere jail, and was tested on FreeBSD 13.1 and FreeBSD 13.2.
Also was tested in the RunTime execution, and the test passes.
Comment 12 Rafael Grether 2023-06-02 18:51:03 UTC
@COMMITER
Comment 13 Mikael Urankar freebsd_committer freebsd_triage 2023-07-18 12:16:31 UTC
committed, wrong pr linked :/
https://cgit.freebsd.org/ports/commit/?id=a68c1f6ccab8140d1190a6d29d774672a5602d34

Thanks!