sigsegv

万事皆有因 随着公司的业务不断扩大，我们在2013年底开始逐步的进入Java体系的阶段，不过谁都没有Java的经验，我们就决定自己动手丰衣足食的策略，学习，请教和顾问。经过2014年的一年的努力，成功的组建了一个Java团队，并尝试做了一些新业务和基础性组件。虽然比较顺利，但还是在我心中留下了许多疑问，例如说JVM的安全点和安全区，正好上周出差回来得到了一段时间的放松，又开始阅读了下JVM中的代码。 那么收获有什么呢？ 纠正了自己以前一个错误的认识，VMThread的是JVM用来完成JVM内的事情的线程，并非执行OpCode的线程，而这正执行OpCode的线程是JavaThread。 发现了JVM进入安全区的一些原理，该原理和Linux的信号以及线程是有非常大的关系的。 Linux的线程 在Linux的上古时代，Linux的线程技术和POSIX的标准是不同的，它使用自己的LinuxThread库。这会为我们带来什么影响呢？ 首先，我们说下POSIX是如何定义多线程的，POSIX下一个多线程的进程只有一个PID。从这个定义中，大家可能已经猜出LinuxThread的实现有什么不同了，对，就是LinuxThread下每个线程都有一个PID，每个线程在系统中的表现就如同进程一般。 其次，现代的Linux的线程已经完全符合POSIX的标准了。 总结就是，我们可以忽略这件事情（不要丢鸡蛋）。

So, I'm trying to port a C library (libnfc) to Java using SWIG. I've got to the point of having a compiled shared library, and a basic "nfc_version()" method call will work. However, calling "nfc_init()" to set things up causes a SIGSEGV error. Calling the nfc library directly is fine. The commands I used to generate the shared library: swig -java -I../libnfc/include nfclib.i gcc -c -I/usr/lib/jvm/java-7-openjdk-i386/include/ -I/usr/lib/jvm/java-7-openjdk-i386/include/linux nfclib_wrap.c gcc -shared nfclib_wrap.o ../build/libnfc/libnfc.so libnfc_wrap.so The libnfc.i file: %module nfc %{

I'm using a low cost tablet with Android 4.0.3. Here the log: 06-11 23:36:04.653: D/SynopticElement(1583): Size changed to 200x200 06-11 23:36:04.693: D/dalvikvm(1583): GC_FOR_ALLOC freed 62K, 12% free 7275K/8199K, paused 33ms 06-11 23:36:04.713: D/SynopticElement(1583): Size changed to 190x190 06-11 23:36:04.733: D/dalvikvm(1583): GC_FOR_ALLOC freed 9K, 12% free 7583K/8583K, paused 22ms 06-11 23:36:04.743: A/libc(1583): Fatal signal 11 (SIGSEGV) at 0xc52c9d4c (code=1) Debugging my code: canvas.scale(getWidth(), getWidth()); //I'm drawing a custom component Paint frameBackgroundPainter = new

I have an odd bug in my program, it appears to me that malloc() is causing a SIGSEGV, which as far as my understanding goes does not make any sense. I am using a library called simclist for dynamic lists. Here is a struct that is referenced later: typedef struct { int msgid; int status; void* udata; list_t queue; } msg_t; And here is the code: msg_t* msg = (msg_t*) malloc( sizeof( msg_t ) ); msg->msgid = msgid; msg->status = MSG_STAT_NEW; msg->udata = udata; list_init( &msg->queue ); list_init is where the program fails, here is the code for list_init: /* list initialization */ int list_init

After upgrade from Pycharm 2017.2.3 to Pycharm 2017.1.4 Pycharm's Debugger suggested to build cpython (or sth associated with it): path/to/my/python /opt/pycharm-community-2017.1.4/helpers/pydev/setup_cython.py build_ext --inplace After I did this, Debugger now instantly returns this error: Process finished with exit code 139 (interrupted by signal 11: SIGSEGV) I found out that there was similar issue with cpython ( https://youtrack.jetbrains.com/issue/PY-23273 ) but I cannot use the workaround mentioned there because I am missing the files it suggest to remove... I am not using cython, I wish

I am getting an error message from the Java compiler that I don't understand. I've tested my code on OSX 10.6, 10.9, and Ubuntu 14.04, with both Java 6 and 7. When I run with the Eclipse debugger or from the interpreter (using -Xint option), everything runs fine. Otherwise, I get the following messages: Java 1.6: Invalid memory access of location 0x8 rip=0x1024e9660 Java 1.7: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000000010f7a8262, pid=20344, tid=18179 # # JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 1.7.0_60-b19) #

In my application I handle SIGSEG to produce a backtrace and call abort() to generate a core dump. If I now run a gdb-post-mortem analysis of the core, the thread which caused the SEGFAULT is no longer visible. Is there anything I can do so I see the cause for the SEGFAULT? Best regards, Martin You can use command thread apply all bt or thread apply all bt full to get backtraces of all threads. Might be useful. By the way if you get rid of you handler will your OS create a core file? 来源： https://stackoverflow.com/questions/2652944/how-to-find-which-thread-caused-segfault-in-a-post-mortem-gdb

I tried to create MAP_GROWSDOWN mapping with the expectation it would grow automatically. As specified in the manual page: MAP_GROWSDOWN This flag is used for stacks. It indicates to the kernel virtual memory system that the mapping should extend downward in memory. The return address is one page lower than the memory area that is actually created in the process's virtual address space. Touching an address in the "guard" page below the mapping will cause the mapping to grow by a page . This growth can be repeated until the mapping grows to within a page of the high end of the next lower

I'm constructing a program which uses mprotect() to restrict a block of memory from accessing. When the memory is requested, a SIGSEGV is thrown which I listen for using a signal() call. Once the SIGSEGV has been detected, I need to somehow access the pointer to the memory that was requested (that threw the fault) and the size of the segment requested. Is this possible? void fifoSigHandler(){ // Needs to only remove protection from requested block of virtual memory mprotect(fifoVm,(size_t)fifoVm_size,PROT_WRITE); printf("Caught Seg Fault"); } void fifo_init(void* vm, int vm_size, int n_frames,

I have following code in my .zshrc: TMOUT=1 TRAPALRM() { zle reset-prompt } After triggering menu completion all items from menu, except highlighted one disappear after TRAPALRM triggers and when i keep navigating in menu zsh segvaults after a short time Is there any fix or workaround for this? EDIT: zsh version is 5.0.2 on Linux Mint 17 EDIT: i observe same thing on zsh version 5.0.7 on Gentoo I found this workaround, to basically prevent calling "reset-prompt" when in a menu selection : TRAPALRM() { if [ "$WIDGET" != "complete-word" ]; then zle reset-prompt fi } Note that complete-word may