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

SEGV while transcoding #287

Closed
yurivict opened this issue Dec 21, 2022 · 16 comments
Closed

SEGV while transcoding #287

yurivict opened this issue Dec 21, 2022 · 16 comments
Labels
bug
Milestone
v3.35.0

Comments

@yurivict
Copy link

yurivict commented Dec 21, 2022 •
edited
Loading 

[2022-Dec-21 00:36:20.226] 27539 - [info] - [TRANSCODE] [8] - Transcoding file '/xpool/music/Various Artists - New Year's Eve Party Music (2022) Mp3 320kbps [PMEDIA] ⭐️/12. Kool & The Gang - Celebration.mp3'
Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...

Settings are:
image

Version: 3.34.0
OS: FreeBSD 13.1
@yurivict
Copy link
Author

During configure we provide both STB and GraphicsMagick++.
Configure says that it uses STB:

-- IMAGE_LIBRARY set to STB

Why then does the error message contain Magick in it?
Is there some inconsistency in the code?

@epoupon
Copy link
Owner

epoupon commented Dec 21, 2022 •
edited
Loading

I checked and I did not find any code inconsistency. Do you by chance have a callstack of the crash?

@bapt
Copy link

bapt commented Dec 21, 2022

The issue is somewhere in the STB code, when I built with GraphicsMagick instead I don't have any issue at all.
I will try to get a core file and look at the call stack when built with STB.

@epoupon
Copy link
Owner

epoupon commented Dec 21, 2022

Thanks, that would be really helpful!
I may have a clue for the Magick exception: AFAIR the wt lib may use it internally (depend on its compilation options, personally I don't compile it with graphicsMagick support), maybe there some kind of trap in it?

@bapt
Copy link

bapt commented Dec 21, 2022

I can't reproduce when build with debug flags however, when I do build with libasan I do get the following traceback

=================================================================
==74037==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x6160000d3590 in thread T6
10.10.0.1 - - [2022-Dec-21 17:16:39.298] "GET /rest/getCoverArt.view?id=tr-8726&size=550&u=bapt&c=Ultrasonic&f=json&v=1.16.0&p=enc:647A6C32313034 HTTP/1.1" 200 17862
10.10.0.1 - - [2022-Dec-21 17:16:39.311] "GET /rest/getCoverArt.view?id=tr-8726&size=2028&u=bapt&c=Ultrasonic&f=json&v=1.16.0&p=enc:647A6C32313034 HTTP/1.1" 200 43778
10.10.0.1 - - [2022-Dec-21 17:16:39.313] "GET /rest/getCoverArt.view?id=tr-8726&size=2028&u=bapt&c=Ultrasonic&f=json&v=1.16.0&p=enc:647A6C32313034 HTTP/1.1" 200 43778
10.10.0.1 - - [2022-Dec-21 17:16:39.336] "GET /rest/getCoverArt.view?id=tr-8726&size=2028&u=bapt&c=Ultrasonic&f=json&v=1.16.0&p=enc:647A6C32313034 HTTP/1.1" 200 43778
10.10.0.1 - - [2022-Dec-21 17:16:39.429] "GET /rest/getCoverArt.view?id=tr-8726&size=550&u=bapt&c=Ultrasonic&f=json&v=1.16.0&p=enc:647A6C32313034 HTTP/1.1" 200 17862
    #0 0x5964e2 in free /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:111:3
    #1 0x64abf4 in boost::asio::aligned_delete(void*) /usr/local/include/boost/asio/detail/memory.hpp:138:3
    #2 0x80109f6bb in void boost::asio::detail::thread_info_base::deallocate<boost::asio::detail::thread_info_base::default_tag>(boost::asio::detail::thread_info_base::default_tag, boost::asio::detail::thread_info_base*, void*, unsigned long) /usr/local/include/boost/asio/detail/thread_info_base.hpp:198:5
    #3 0x80109f4f4 in boost::asio::detail::thread_info_base::deallocate(boost::asio::detail::thread_info_base*, void*, unsigned long) /usr/local/include/boost/asio/detail/thread_info_base.hpp:129:5
    #4 0x80109f4c4 in boost::asio::asio_handler_deallocate(void*, unsigned long, ...) /usr/local/include/boost/asio/impl/handler_alloc_hook.ipp:51:3
    #5 0x80217b71e in void boost_asio_handler_alloc_helpers::deallocate<ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>(void*, unsigned long, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1&) /usr/local/include/boost/asio/detail/handler_alloc_helpers.hpp:95:3
    #6 0x80217b6d8 in void boost::asio::detail::asio_handler_deallocate<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>(void*, unsigned long, boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>*) /usr/local/include/boost/asio/impl/read.hpp:438:5
    #7 0x80217b69c in void boost_asio_handler_alloc_helpers::deallocate<boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1> >(void*, unsigned long, boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>&) /usr/local/include/boost/asio/detail/handler_alloc_helpers.hpp:95:3
    #8 0x80217b656 in boost::asio::detail::hook_allocator<boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>, boost::asio::detail::descriptor_read_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>, boost::asio::any_io_executor> >::deallocate(boost::asio::detail::descriptor_read_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>, boost::asio::any_io_executor>*, unsigned long) /usr/local/include/boost/asio/detail/handler_alloc_helpers.hpp:137:5
    #9 0x80217b45a in boost::asio::detail::descriptor_read_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>, boost::asio::any_io_executor>::ptr::reset() /usr/local/include/boost/asio/detail/descriptor_read_op.hpp:89:3
    #10 0x80217ac3b in boost::asio::detail::descriptor_read_op<boost::asio::mutable_buffers_1, boost::asio::detail::read_op<boost::asio::posix::basic_stream_descriptor<boost::asio::any_io_executor>, boost::asio::mutable_buffers_1, boost::asio::mutable_buffer const*, boost::asio::detail::transfer_all_t, ChildProcess::asyncRead(std::byte*, unsigned long, std::__1::function<void (IChildProcess::ReadResult, unsigned long)>)::$_1>, boost::asio::any_io_executor>::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) /usr/local/include/boost/asio/detail/descriptor_read_op.hpp:127:7
    #11 0x64b3e3 in boost::asio::detail::scheduler_operation::complete(void*, boost::system::error_code const&, unsigned long) /usr/local/include/boost/asio/detail/scheduler_operation.hpp:40:5
    #12 0x64a170 in boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) /usr/local/include/boost/asio/detail/impl/scheduler.ipp:492:12
    #13 0x64944a in boost::asio::detail::scheduler::run(boost::system::error_code&) /usr/local/include/boost/asio/detail/impl/scheduler.ipp:210:10
    #14 0x801018e86 in boost::asio::io_context::run() /usr/local/include/boost/asio/impl/io_context.ipp:63:24
    #15 0x8021a949e in IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0::operator()() const /usr/home/bapt/dev/ports/multimedia/lms/work/lms-3.34.0/src/libs/utils/impl/IOContextRunner.cpp:37:16
    #16 0x8021a92f4 in decltype(static_cast<IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0>(fp)()) std::__1::__invoke<IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0>(IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0&&) /usr/include/c++/v1/type_traits:3918:1
    #17 0x8021a92d4 in void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0>&, std::__1::__tuple_indices<>) /usr/include/c++/v1/thread:280:5
    #18 0x8021a8f01 in void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0> >(void*) /usr/include/c++/v1/thread:291:5
    #19 0x800f3b839  (/lib/libthr.so.3+0x10839)

0x6160000d3590 is located 16 bytes inside of 576-byte region [0x6160000d3580,0x6160000d37c0)
allocated by thread T11 here:
    #0 0x59662d in malloc /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
    #1 0x800e27efe  (/usr/local/lib/libwthttp.so.4.8.0+0x6aefe)
    #2 0x800ea0220  (/usr/local/lib/libwthttp.so.4.8.0+0xe3220)
    #3 0x800e9fe2b  (/usr/local/lib/libwthttp.so.4.8.0+0xe2e2b)
    #4 0x800e9c89b  (/usr/local/lib/libwthttp.so.4.8.0+0xdf89b)
    #5 0x800e24995  (/usr/local/lib/libwthttp.so.4.8.0+0x67995)
    #6 0x800e25def  (/usr/local/lib/libwthttp.so.4.8.0+0x68def)
    #7 0x800e260a4  (/usr/local/lib/libwthttp.so.4.8.0+0x690a4)
    #8 0x800e9f33d  (/usr/local/lib/libwthttp.so.4.8.0+0xe233d)
    #9 0x800e9f1ea  (/usr/local/lib/libwthttp.so.4.8.0+0xe21ea)
    #10 0x800e9f062  (/usr/local/lib/libwthttp.so.4.8.0+0xe2062)
    #11 0x800ea0102  (/usr/local/lib/libwthttp.so.4.8.0+0xe3102)
    #12 0x800ea11ca  (/usr/local/lib/libwthttp.so.4.8.0+0xe41ca)
    #13 0x800e28abf  (/usr/local/lib/libwthttp.so.4.8.0+0x6babf)
    #14 0x800ea0f18  (/usr/local/lib/libwthttp.so.4.8.0+0xe3f18)
    #15 0x800ea0c00  (/usr/local/lib/libwthttp.so.4.8.0+0xe3c00)
    #16 0x800ea0917  (/usr/local/lib/libwthttp.so.4.8.0+0xe3917)
    #17 0x802837175  (/usr/local/lib/libwt.so.4.8.0+0x437175)
    #18 0x802836c00  (/usr/local/lib/libwt.so.4.8.0+0x436c00)
    #19 0x802833ad5  (/usr/local/lib/libwt.so.4.8.0+0x433ad5)
    #20 0x80283ae51  (/usr/local/lib/libwt.so.4.8.0+0x43ae51)
    #21 0x800f3b839  (/lib/libthr.so.3+0x10839)

Thread T6 created by T0 here:
    #0 0x58c03c in pthread_create /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:207:3
    #1 0x8021ab4e8 in std::__1::__libcpp_thread_create(pthread**, void* (*)(void*), void*) /usr/include/c++/v1/__threading_support:514:10
    #2 0x8021a8882 in std::__1::thread::thread<IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0, void>(IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0&&) /usr/include/c++/v1/thread:307:16
    #3 0x8021a8650 in void std::__1::allocator<std::__1::thread>::construct<std::__1::thread, IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0>(std::__1::thread*, IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0&&) /usr/include/c++/v1/__memory/allocator.h:154:28
    #4 0x8021a860c in void std::__1::allocator_traits<std::__1::allocator<std::__1::thread> >::construct<std::__1::thread, IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0, void>(std::__1::allocator<std::__1::thread>&, std::__1::thread*, IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0&&) /usr/include/c++/v1/__memory/allocator_traits.h:290:13
    #5 0x8021a815d in void std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread> >::__construct_one_at_end<IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0>(IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0&&) /usr/include/c++/v1/vector:948:5
    #6 0x8021a78b3 in std::__1::thread& std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread> >::emplace_back<IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0>(IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long)::$_0&&) /usr/include/c++/v1/vector:1706:9
    #7 0x8021a769d in IOContextRunner::IOContextRunner(boost::asio::io_context&, unsigned long) /usr/home/bapt/dev/ports/multimedia/lms/work/lms-3.34.0/src/libs/utils/impl/IOContextRunner.cpp:33:12
    #8 0x5c5058 in main /usr/home/bapt/dev/ports/multimedia/lms/work/lms-3.34.0/src/lms/main.cpp:228:19
    #9 0x53ddef in _start /usr/src/lib/csu/amd64/crt1_c.c:75:7
    #10 0x800b3b007  (<unknown module>)

Thread T11 created by T0 here:
    #0 0x58c03c in pthread_create /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:207:3
    #1 0x8028339fc  (/usr/local/lib/libwt.so.4.8.0+0x4339fc)
    #2 0x802832fd1 in Wt::WIOService::start() (/usr/local/lib/libwt.so.4.8.0+0x432fd1)
    #3 0x800ea36e3 in Wt::WServer::start() (/usr/local/lib/libwthttp.so.4.8.0+0xe66e3)
    #4 0x5c6f0b in main /usr/home/bapt/dev/ports/multimedia/lms/work/lms-3.34.0/src/lms/main.cpp:293:10
    #5 0x53ddef in _start /usr/src/lib/csu/amd64/crt1_c.c:75:7
    #6 0x800b3b007  (<unknown module>)

@epoupon epoupon added the bug label Dec 21, 2022
@epoupon
Copy link
Owner

epoupon commented Dec 21, 2022

Ok this callstack is unrelated to image/cover handling, but it is about transcoding (we fork/exec to lauch ffmpeg).
This is likely a bug in lms. Not sure why using the graphicsMagick backend hides this though, maybe there are two problems here.
Will try to reproduce on debian with asan and/or valgrind

@epoupon epoupon added this to the v3.35.0 milestone Dec 21, 2022
@epoupon epoupon mentioned this issue Dec 21, 2022
Closed
@yurivict
Copy link
Author

@epoupon Why are there two choices for image library, STB and GraphicsMagick++? Is one of them better than the other? Do they provide different functionality?

@epoupon
Copy link
Owner

epoupon commented Dec 22, 2022

STB eats far less memory, but I kept the other one for distribs that do not package it

@yurivict
Copy link
Author

I've got a similar SEGV without subsonic transcoding and without STB involved:

127.0.0.1 - - [2022-Dec-22 21:21:15.687] "POST /?wtd=aSrE4GwWlP6O7Ey2 HTTP/1.1" 200 1129
127.0.0.1 - - [2022-Dec-22 21:21:15.702] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=4&size=128 HTTP/1.1" 200 2684
127.0.0.1 - - [2022-Dec-22 21:21:15.713] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=18&size=128 HTTP/1.1" 200 5176
127.0.0.1 - - [2022-Dec-22 21:21:15.718] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=19&size=128 HTTP/1.1" 200 4613
127.0.0.1 - - [2022-Dec-22 21:21:15.736] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=17&size=512 HTTP/1.1" 200 72649
127.0.0.1 - - [2022-Dec-22 21:21:15.778] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=19&size=512 HTTP/1.1" 200 44958
127.0.0.1 - - [2022-Dec-22 21:21:15.904] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=1&size=512 HTTP/1.1" 200 50357
127.0.0.1 - - [2022-Dec-22 21:21:16.111] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=15&size=512 HTTP/1.1" 200 32374
[2022-Dec-22 21:21:16.151] 36907 [/ aSrE4GwWlP6O7Ey2] [info] - [TRANSCODE] [9] - Transcoding file '/xpool/qBT_dir/Various Artists - New Year's Eve Party Music (2022) Mp3 320kbps [PMEDIA] ⭐️/79. Donna Summer - Hot Stuff (Single Version).mp3'
127.0.0.1 - - [2022-Dec-22 21:21:16.304] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=2&size=128 HTTP/1.1" 200 2684
127.0.0.1 - - [2022-Dec-22 21:21:16.317] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=6&size=128 HTTP/1.1" 200 2684
[mp3 @ 0x88896ac00] Estimating duration from bitrate, this may be inaccurate
[mp3 @ 0x887602400] Estimating duration from bitrate, this may be inaccurate 
127.0.0.1 - - [2022-Dec-22 21:21:16.584] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=6&size=512 HTTP/1.1" 200 15382
127.0.0.1 - - [2022-Dec-22 21:21:16.603] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=4&size=512 HTTP/1.1" 200 15382
127.0.0.1 - - [2022-Dec-22 21:21:16.603] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=8&size=512 HTTP/1.1" 200 35550
127.0.0.1 - - [2022-Dec-22 21:21:16.605] "GET /?wtd=aSrE4GwWlP6O7Ey2&request=resource&resource=o8y7xpy&ver=1&releaseid=16&size=512 HTTP/1.1" 200 37434
Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...

Maybe it was local transcoding, not sure.

@epoupon
Copy link
Owner

epoupon commented Dec 23, 2022

Thanks for the info. Well it would confirm this is not likely to be related to the image library backend. You can set the log level to * in lms.conf, we will get way more relevant debug info

@yurivict
Copy link
Author

Log level is set to:

log-config = "* -debug -info:WebRequest";

@epoupon
Copy link
Owner

epoupon commented Dec 23, 2022

You can remove -debug to have debug entries

@yurivict
Copy link
Author

No additional details w/out -debug:

127.0.0.1 - - [2022-Dec-23 01:19:33.833] "GET /?wtd=t2rsFenZQAYZnFsC&request=resource&resource=ozwb64n&ver=1&releaseid=11&size=128 HTTP/1.1" 200 2348
127.0.0.1 - - [2022-Dec-23 01:19:33.839] "POST /?wtd=t2rsFenZQAYZnFsC HTTP/1.1" 200 2309
127.0.0.1 - - [2022-Dec-23 01:19:33.889] "POST /?wtd=t2rsFenZQAYZnFsC HTTP/1.1" 200 2288
127.0.0.1 - - [2022-Dec-23 01:19:33.915] "POST /?wtd=t2rsFenZQAYZnFsC HTTP/1.1" 200 2367
127.0.0.1 - - [2022-Dec-23 01:19:33.963] "POST /?wtd=t2rsFenZQAYZnFsC HTTP/1.1" 200 2319
Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...

epoupon added a commit that referenced this issue Dec 30, 2022
@epoupon
Simplified interface + fixed segfault when eof is reached. ref #287
c6fe63f
@epoupon
Copy link
Owner

epoupon commented Dec 30, 2022

Hi @bapt @yurivict , I found an issue that may explain your crash. Could you please try with c6fe63f ?

@epoupon
Copy link
Owner

epoupon commented Dec 30, 2022 •
edited
Loading

And indeed, GraphicsMagick does set up its own signal handler and intercepts the crash (see InitializeMagickSignalHandlers at http://hg.code.sf.net/p/graphicsmagick/code/file/tip/magick/magick.c#l1055), since GM is used by the wt library, this explains the misleading message you got.
(By the way, it does not sound right that a library sets up such low level handlers, what if several libraries do the same?)

@epoupon epoupon closed this as completed Jan 6, 2023
@bapt
Copy link

bapt commented Jan 23, 2023

I can confirm the fix on my side! thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
v3.35.0
Development

No branches or pull requests
3 participants
@bapt @yurivict @epoupon