I got a core dump file and using gdb on that revealed that it is a segmentation fault. I have no clue as to what might be the issue!
Program terminated with signal 11, Segmentation fault.
#0 enqueue_task (ptp=<optimized out>, ptqp=0x0) at beam/erl_port_task.c:327
327 beam/erl_port_task.c: No such file or directory.
Any pointers as to what might be the issue ? Thanks!
Related
I am seeing the following error in my logs:
2022-07-22 03:50:55.262 [upsell_app] [INFO] /usr/local/bundle/gems/activerecord-6.0.4.4/lib/active_record/connection_adapters/postgresql/quoting.rb:21: [BUG] Segmentation fault at 0x00007f21af9a52e8
"dt":"2022-07-22 12:50:55.262 UTC"
"level_string":"info"
"message_string":"/usr/local/bundle/gems/activerecord-6.0.4.4/lib/active_record/connection_adapters/postgresql/quoting.rb:21: [BUG] Segmentation fault at 0x00007f21af9a52e8"
"platform_string":"Syslog"
syslog
"appname_string":"sidekiq-imports"
"facility_string":"user"
"host_string":"app"
"hostname_string":"app"
"source_ip_string":"10.0.5.150"
"version_integer":1
I am not sure how to debug it because it happens randomly and only on production. Can. anyone advise?
Here's the problem: Unable to start an existing Rails project after upgrading to MacOS 10.15.1. The terminal shows this (below) after Rails s and going to localhost:3000.
SEGV received in SEGV handler [1]
1438 illegal hardware instruction rails s
Note: The latest version of Xcode / command line is installed.
After upgrading the OS successfully (MacOS 10.15.1), I followed the MacPorts migration guide successfully. Further, I successfully reinstalled RVM with Ruby 2.6.1, 2.6.3 and 2.6.5.
Next, installed gem Rails -v 5.2.3 without issue. Tested this out with Rails new TestProj, it created a new project successfully, bundled and started the server with Rails s. No issues and saw the "Yay you're on Rails" page. So far so good.
Then I CD into an existing Rails project, which was built on MacOS 10.14.x (Mojave) did a bundle update without any issues. Followed by a rails s, Puma started without issue. Here's where it gets strange, literally the second I goto the URL "localhost:3000" I immediately get this error.
SEGV received in SEGV handler [1] <- this repeated
1438 illegal hardware instruction rails s
I thought it might be a gem issue, tried installing the same gem set into the TestProj and everything work perfectly with a Puma starting and loading "Yay...". Finally, I've tried cloning the repo, bundling and I get the same error message. I'm pasting what I believe is the most important part of the log file into this post. I wonder if there is something in the Rails app that specifies certain hardware that needs updating? My apologies for its length, Hopefully, someone can interpret this better than I can and help troubleshoot. I'm happy to provide more information. Just not sure what else besides the log file you might need. Let me know. Thanks!
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000000f8
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: ruby [1438]
VM Regions Near 0xf8:
-->
__TEXT 0000000103679000-000000010367a000 [ 4K] r-x/r-x SM=COW /Users/USER/*
Application Specific Information:
abort() called
Thread 11 Crashed:: thread_pool.rb*
0 libsystem_pthread.dylib 0x00007fff681ac65f pthread_kill + 276
1 libsystem_c.dylib 0x00007fff68077a1c abort + 120
2 libruby.2.6.dylib 0x00000001038261d9 ruby_abort + 9
3 libruby.2.6.dylib 0x0000000103826160 check_reserved_signal_ + 160 (signal.c:854)
4 libruby.2.6.dylib 0x0000000103825fa4 sigsegv + 36 (signal.c:997)
5 libsystem_platform.dylib 0x00007fff681a1b1d _sigtramp + 29
6 ??? 000000000000000000 0 + 0
7 libsystem_c.dylib 0x00007fff68077a1c abort + 120
I expect to cd into the existing RoR application and run rails s to start the server. Then go to http://localhost:3000 and see the application without crashing. The actual results are the following:
...
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
[1] 16523 illegal hardware instruction rails s
After updating mvvmcross to version 5.0.1 application crashes during start with exception
No native Android stacktrace (see debuggerd output).
[mono-rt] Got a SIGSEGV while executing native code. This usually indicates
[mono-rt] a fatal error in the mono runtime or one of the native libraries
[mono-rt] used by your application.
Fatal signal 11 (SIGSEGV), code 2, fault addr 0xc5c3ff70 in tid 9451 (Thread-5)
No any stacktrace or error message appeared
What changed on this framework version?
My server keeps getting filled up with ejabberd crash logs every few hours - it seems that the ejabberd server keep crashing and the crash log will fill the server's free space until the server has no more space left (GBs of crash logs). The crash logs start with something like this:
=erl_crash_dump:0.1
Tue Feb 4 23:44:02 2014
Slogan: Kernel pid terminated (application_controller) ({application_start_failure,kernel, {shutdown,{kernel,start,[normal,[]]}}})
System version: Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]
Compiled: Fri Dec 16 03:22:15 2011
Taints:
Atoms: 4574
Can anyone see something from the crash log and let me know what's happening?
In this case, the crash dump is unlikely to tell you very much - it tells you that the kernel application shut down ({shutdown,{kernel,start,[normal,[]]}}), but it doesn't say why. In the error log you should find a number of crash reports and error messages that led to the node shutting down.
Crash dumps are much more useful if the node crashes because it runs out of memory. In that case, you can usually see which process behaved badly.
I have an OpenCV 2.4.6 application (compiled with TBB), running in ARM cortex A9 board (Odroid X2). I get segmentation fault when running the application, so first I debug with gdb. gdb cannot finish the backtrace, giving message:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
But it did output some trace, leading to TBB:
#3 0x001752f4 in tbb::interface6::internal::start_for<tbb::blocked_range<int>, (anonymous namespace)::ProxyLoopBody, tbb::auto_partitioner con)
()
#4 0x00502d9e in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) ()
#5 0x00503610 in tbb::internal::arena::process(tbb::internal::generic_scheduler&) ()
#6 0x00506aa0 in tbb::internal::market::process(rml::job&) ()
#7 0x0050773e in tbb::internal::rml::private_worker::run() ()
#8 0x00507a7a in tbb::internal::rml::private_worker::thread_routine(void*) ()
#9 0xb6fafcb0 in start_thread () from /usr/lib/libpthread.so.0
I tried running without TBB, and it runs fine. But I need TBB because it helps my application runs 2-3x faster, so I debug with Valgrind based on my previous experience with segmentation fault and multithreading problem. Unfortunately too, Valgrind stops and messages appear, seems related to kernel (?):
[27140.140000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[27140.140000] pgd = ebf10000
[27140.140000] [00000000] *pgd=6a02e831, *pte=00000000, *ppte=00000000
[27140.140000] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[27140.140000] Modules linked in: r8712u(C) ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill vfat fat smsc95xx uvcvideo usbnet vide6
...
[27140.140000] Code: e3110001 0a00004d e59f1150 e5911000 (e7912102)
[27140.140000] ---[ end trace ce3bd4d9f0a91ec4 ]---
[27140.140000] note: memcheck-arm-li[5626] exited with preempt_count 1
I am pretty new to Linux and debugging tool, thus I will be most grateful if you can help me understand what happened. Is it my application runs bad? Is it Valgrind that cause the crash? Do I need to reinstall Linux?
Oh yeah, I cannot type anything to the console after the message, but if I turn the device off, then on again, I can start using Linux again. Thanks!