The application constantly gives data, how can I understand what is happening?
SWI-Prolog [thread 3 (httpd@8081_1) at Sat Dec 2 18:49:41 2023]: received fatal signal 11 (segv)
C-stack trace labeled "crash":
Segmentation fault
The application constantly gives data, how can I understand what is happening?
SWI-Prolog [thread 3 (httpd@8081_1) at Sat Dec 2 18:49:41 2023]: received fatal signal 11 (segv)
C-stack trace labeled "crash":
Segmentation fault
No stack trace? What platform? Typically, making the code to replicate available is the way to get these things sorted out. Knowing which request triggers this (?- debug(http(request)).
) and include the source code for this handler may help to create a program that reproduces this.
No stack trace. maybe it’s because I’m running a qlf file?
No. But, stack traces are not available on all architectures. That is why I keep asking for details.
cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 42
Model name: Intel Xeon E5 (Sandy Bridge)
Stepping: 1
CPU MHz: 2299.996
BogoMIPS: 4599.99
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
NUMA node0 CPU(s): 0,1
Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti xsaveopt
SWI-Prolog version 9.1.4 for x86_64-linux
Installed from PPA, Snap, source, …? If you install from source you’d normally get a usable backtrace, so probably not Creating a minimal reproducing example is probably the way to go. The alternative is to install from source and see whether this gets a more usable backtrace. On failure thereof you can build the debug version and either hope its additional debugging tools give a hint or use gdb (the C debugger) to get a clue.
As is, it is likely a bug as the system should not crash unless bad foreign plugins are added. Nobody can have any cue what it might be related to though.
I compiled from sources
that’s all we’ve been able to see so far
% [Thread httpd@8081_3] Field: [host('v.hopto.org'),port(8081),user_agent('Bitrix24 Webhook Engine'),content_length(780),content_type('application/x-www-form-urlencoded'),accept_encoding(gzip),connection(close)]
% [Thread httpd@8081_3] [818] post /event ...
Segmentation fault
You know the source code and the request. We don’t. Without giving something to reproduce, you’ll have to debug yourself. Sorry.
How can this help?
SWI-Prolog [thread 6 (httpd@8081_4) at Wed Dec 6 18:10:53 2023]: received fatal signal 11 (segv)
C-stack trace labeled "crash":
[0] save_backtrace() at /home/oper/Programs/swipl-devel/src/os/pl-cstack.c:337 [0x7efd14bfa2ed]
[1] print_c_backtrace() at /home/oper/Programs/swipl-devel/src/os/pl-cstack.c:909 [0x7efd14bfa47c]
[2] sigCrashHandler() at /home/oper/Programs/swipl-devel/src/os/pl-cstack.c:947 [0x7efd14bfa5a3]
[3] killpg() at ??:? [0x7efd14714f10]
[4] el_wset() at ??:? [0x7efd095e7440]
[5] el_set() at ??:? [0x7efd095e87e2]
[6] el_sighandler() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:347 [0x7efd0982b671]
[7] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[8] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[9] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[10] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[11] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[12] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[13] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[14] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[15] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[16] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[17] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[18] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[19] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[20] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[21] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[22] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[23] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[24] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[25] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[26] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
[27] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7efd0982b6bd]
Segmentation fault
It suggests you are somehow mixing up the I/O streams involved in handling the HTTP request. That means you code is probably wrong. As we have no clue about this code, there is little we can do.
How can I do that ? What are the ways to mix streams?
The message that you ignore is that you refuse to provide a reproducible example; instead you insist on taking other people’s time, for no obvious benefit. So you get to keep your secrets and we get to waste our time. Sounds like a sweet deal.
I don’t understand how to do this, there’s a lot of code. I’m gradually getting closer to understanding the problem. Now I need to understand how to mix the output
does this give you something to understand?
Prolog stack:
[35] socket:$host_address/3 [PC=1 in supervisor]
[34] socket:host_address/3 [PC=12 in clause 1]
[33] socket:tcp_connect_direct/4 [PC=47 in clause 1]
[32] socket:tcp_connect/3 [PC=98 in clause 1]
[31] http_open:open_socket/3 [PC=20 in clause 1]
[29] http_open:try_http_proxy/4 [PC=178 in clause 1]
[27] http_client:http_get/3 [PC=24 in clause 1]
[25] system:catch/3 [PC=2 in clause 1]
[24] server_rpc:quickorder/3 [PC=81 in clause 1]
[23] server_rpc:quickrun/3 [PC=16 in clause 1]
[22] server_rpc:oncrmdealupdate/1 [PC=101 in clause 1]
[21] server_rpc:do_event/1 [PC=15 in clause 2]
[20] server_rpc:handle_event/1 [PC=38 in clause 1]
[19] http_dispatch:call_action/2 [PC=8 in clause 1]
[17] time:run_alarm_goal/2 [PC=6 in clause 1]
[16] system:setup_call_catcher_cleanup/4 [PC=5 in clause 1]
[8] httpd_wrapper:call_handler/3 [PC=35 in clause 2]
[7] system:catch/3 [PC=2 in clause 1]
[6] httpd_wrapper:handler_with_output_to/5 [PC=24 in clause 1]
[5] httpd_wrapper:handler_with_output_to/5 [PC=23 in clause 2]
[4] httpd_wrapper:http_wrapper/5 [PC=166 in clause 1]
[3] thread_httpd:http_process/4 [PC=64 in clause 1]
[2] system:catch/3 [PC=2 in clause 1]
[1] thread_httpd:http_worker/1 [PC=168 in clause 1]
[0] system:$c_call_prolog/0 [PC=0 in top query clause]
Running on_halt hooks with status 139
Killing 3209 with default signal handlers
Segmentation fault
I think there is an error…
Without the C stack and without the exact call, no. It it reproduces, try
?- trace(socket:'$host_address'/3).
which will hopefully tell the exact call going wrong.
with trace
[Thread 5] T [36] Call: socket:'$host_address'('vodanakhodka.bitrix24.ru', _5460, [type(stream)])
[Thread 5] T [36 +2.0ms] Exit: socket:'$host_address'('vodanakhodka.bitrix24.ru', [sockaddr{address:ip(89, 208, 228, 119), domain:inet, type:s
tream}, sockaddr{address:ip(178, 132, 201, 50), domain:inet, type:stream}, sockaddr{address:ip(178, 132, 201, 51), domain:inet, type:stream}, s
ockaddr{address:ip(178, 132, 201, 52), domain:inet, type:stream}, sockaddr{address:ip(95, 163, 249, 170), domain:inet, type:stream}, sockaddr{a
ddress:ip(..., ..., ..., ...), domain:inet, type:stream}], [type(stream)])
SWI-Prolog [thread 4 (httpd@8081_2) at Thu Dec 21 19:12:28 2023]: received fatal signal 11 (segv)
C-stack trace labeled "crash":
[0] save_backtrace() at /home/oper/Programs/swipl-devel/src/os/pl-cstack.c:337 [0x7f03670842ed]
[1] print_c_backtrace() at /home/oper/Programs/swipl-devel/src/os/pl-cstack.c:909 [0x7f036708447c]
[2] sigCrashHandler() at /home/oper/Programs/swipl-devel/src/os/pl-cstack.c:947 [0x7f03670845a3]
[3] killpg() at ??:? [0x7f0366b9ef10]
[4] el_wset() at ??:? [0x7f035bebc440]
[5] el_set() at ??:? [0x7f035bebd7e2]
[6] el_sighandler() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:347 [0x7f035c100671]
[7] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[8] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[9] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[10] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[11] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[12] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[13] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[14] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[15] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[16] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[17] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[18] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[19] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[20] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[21] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[22] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[23] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[24] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[25] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[26] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[27] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[28] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
[29] get_context() at /home/oper/Programs/swipl-devel/packages/libedit/libedit4pl.c:146 [0x7f035c1006bd]
This looks like a different crash. Something we have seen in this thread before. This time you omit the Prolog stack, so the information is completely disjoint with the previous report. This looks like doing something wrong with the HTTP streams. The crash in '$host_address'
looked like a memory management issue in internet address lookup.
Again, and I fear for the last time: if you do not provide proper error reports, which ideally includes code we can run or at least snippets of what happens around the crash with as complete as you can get stack traces and goal arguments, there is no way anyone can help you.
the prologue does not provide any extended information. I would be happy if there was a detailed report of the fall