segmentation-fault
The following code receives seg fault on line 2:
char *str = "string";
str[0] = 'z'; // could be also written as *str = 'z'
printf("%s\n", str);
While this works perfectly well:
char str[] = "string";
str[0] = 'z';
printf("%s\n", str);
Tested with MSVC and GCC.
Definitive List of Common Reasons for Segmentation FaultsNOTE: We have a lot of segfault questions, with largely the same answers, so I'm trying to collapse them into a canonical question like we have for undefined reference.
Although we have a question covering what a segmentation fault is, it covers the what, but doesn't list many reasons. The top answer says "there are many reasons", and only lists one, and most of the other answers don't list any reasons.
All in all, I believe we need a well-organized community wiki on this topic, which lists all the common causes (and then some) to get segfaults. The purpose is to aid in debugging, as mentioned in the answer's disclaimer.
I know what a segmentation fault is, but it can be hard to spot in the code without knowing what they often look like. Although there are, no doubt, far too many to list exhaustively, what are the most common causes of segmentation faults in C and C++?
How do you read a segfault kernel log messageThis can be a very simple question, I'm am attempting to debug an application which generates the following segfault error in the kern.log
kernel: myapp[15514]: segfault at 794ef0 ip 080513b sp 794ef0 error 6 in myapp[8048000+24000]
Here are my questions:
Is there any documentation as to what are the diff error numbers on segfault, in this instance it is error 6, but i've seen error 4, 5
What is the meaning of the information at bf794ef0 ip 0805130b sp bf794ef0 and myapp[8048000+24000]?
So far i was able to compile with symbols, and when i do a x 0x8048000+24000 it returns a symbol, is that the correct way of doing it? My assumptions thus far are the following:
I have a class called Object which stores some data.
I would like to return it by reference using a function like this:
Object& return_Object();
Then, in my code, I would call it like this:
Object myObject = return_Object();
I have written code like this and it compiles. However, when I run the code, I consistently get a seg fault. What is the proper way to return a class object by reference?
Segmentation fault on large array sizesThe following code gives me a segmentation fault when run on a 2Gb machine, but works on a 4GB machine.
int main()
{
int c[1000000];
cout << "done\n";
return 0;
}
The size of the array is just 4Mb. Is there a limit on the size of an array that can be used in c++?
Determine the line of code that causes a segmentation fault?How does one determine where the mistake is in the code that causes a segmentation fault?
Can my compiler (gcc) show the location of the fault in the program?
I've been reading the other posts on tracking down the reasons for getting a SIGSEGV in an Android app. I plan to scour my app for possible NullPointers related to Canvas use, but my SIGSEGV barfs up a different memory address each time. Plus I've seen code=1 and code=2. If the memory address was 0x00000000, I'd have a clue it is a NullPointer.
The last one I got was a code=2:
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
Any suggestions on how to track this down?
I have a suspect, but I'm not keen on experimenting with it yet. My app uses the OSMDroid API for offline mapping. The OverlayItem class represents markers/nodes on the map. I have a Service that collects data via the network to populate the OverlayItem which are then displayed on the map. In an effort to simplify my design, I extended OverlayItem into my own NodeOverlayItem class, which includes some addition attributes I use in the UI Activity and in the Service. This gave me a single point of Item information for the UI and Service. I used Intents to broadcast to the Activity to refresh the UI map when something changed. The Activity binds to the Service and there's a Service method to get the list of NodeOverlayItem's. I think it might be the OSMDroid API's use of OverlayItem, and my Service updating node information at the same time. (a concurrency issue)
As I write this I think that's really the problem. The headache isn't splitting out the Node and OverlayItem from NodeOverlayItem, it's that the Activity will need some data from the Node, that the Service holds. Plus when the Activity is created (onResume, etc...) the OverlayItem objects will need to be re-created from the Node data that the Service has been maintaining while the Activity was away. e.g. You start the app, the Service collects data, the UI displays it, you go to Home, then back to the app, the Activity will need to pull and re-create the OverlayItem's from the latest Service node data.
I know this isn't a great or clear questions. It's like all my SO questions are niche or obscure. If anyone has a suggestion on how to interpret those SIGSEGV errors, it would be greatly appreciated!
UPDATE Here's the latest crash captured during a debug session. I have 3 of these devices being used for testing and they don't all crash reliably when I'm developing and testing. I included a bit extra just so the GC logging could be noted. You can see the problem is probably not related to memory exhaustion.
03-03 02:02:38.328: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.328: I/CommService(7477): Already processed this packet. It's a re-broadcast from another node, or from myself. It's not a repeat broadcast though.
03-03 02:02:38.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:38.460: D/CommService(7477): Monitoring nodes...
03-03 02:02:38.515: D/dalvikvm(7477): GC_CONCURRENT freed 2050K, 16% free 17151K/20359K, paused 3ms+6ms
03-03 02:02:38.515: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.515: D/CommService(7477): Forwarding packet (4f68802cf10684a83ac4936ebb3c934d) along to other nodes.
03-03 02:02:38.609: I/CommService(7477): Received packet from: 192.168.1.100
03-03 02:02:38.609: D/CommService(7477): Forwarding packet (e4bc81e91ec92d06f83e03068f52ab4) along to other nodes.
03-03 02:02:38.609: D/CommService(7477): Already processed this packet: 4204a5b27745ffe5e4f8458e227044bf
03-03 02:02:38.609: A/libc(7477): Fatal signal 11 (SIGSEGV) at 0x68f52abc (code=1)
03-03 02:02:38.914: I/DEBUG(4008): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-03 02:02:38.914: I/DEBUG(4008): Build fingerprint: 'Lenovo/IdeaTab_A1107/A1107:4.0.4/MR1/eng.user.20120719.150703:user/release-keys'
03-03 02:02:38.914: I/DEBUG(4008): pid: 7477, tid: 7712 >>> com.test.testm <<<
03-03 02:02:38.914: I/DEBUG(4008): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 68f52abc
03-03 02:02:38.914: I/DEBUG(4008): r0 68f52ab4 r1 412ef268 r2 4d9c3bf4 r3 412ef268
03-03 02:02:38.914: I/DEBUG(4008): r4 001ad8f8 r5 4d9c3bf4 r6 412ef268 r7 4c479df8
03-03 02:02:38.914: I/DEBUG(4008): r8 4d9c3c0c r9 4c479dec 10 46cf260a fp 4d9c3c24
03-03 02:02:38.914: I/DEBUG(4008): ip 40262a04 sp 4d9c3bc8 lr 402d01dd pc 402d0182 cpsr 00000030
03-03 02:02:38.914: I/DEBUG(4008): d0 00000001000c0102 d1 3a22364574614c7d
03-03 02:02:38.914: I/DEBUG(4008): d2 403fc0000000007d d3 363737343433350a
03-03 02:02:38.914: I/DEBUG(4008): d4 49544341223a2273 d5 6f6567222c224556
03-03 02:02:38.914: I/DEBUG(4008): d6 3a223645676e6f4c d7 000000013835372d
03-03 02:02:38.914: I/DEBUG(4008): d8 0000000000000000 d9 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d10 0000000000000000 d11 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d12 4040000000000000 d13 0000000000000021
03-03 02:02:38.914: I/DEBUG(4008): d14 0000000000000000 d15 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d16 3fe62e42fefa39ef d17 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d18 3fe62e42fee00000 d19 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d20 0000000000000000 d21 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d22 4028000000000000 d23 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d24 0000000000000000 d25 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d26 0000000000000000 d27 c028000000000000
03-03 02:02:38.914: I/DEBUG(4008): d28 0000000000000000 d29 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d30 3ff0000000000000 d31 3fecccccb5c28f6e
03-03 02:02:38.914: I/DEBUG(4008): scr 60000013
03-03 02:02:39.046: I/DEBUG(4008): #00 pc 0006b182 /system/lib/libcrypto.so (EVP_DigestFinal_ex)
03-03 02:02:39.046: I/DEBUG(4008): #01 pc 0006b1d8 /system/lib/libcrypto.so (EVP_DigestFinal)
03-03 02:02:39.054: I/DEBUG(4008): #02 pc 0001f814 /system/lib/libnativehelper.so
03-03 02:02:39.054: I/DEBUG(4008): #03 pc 0001ec30 /system/lib/libdvm.so (dvmPlatformInvoke)
03-03 02:02:39.054: I/DEBUG(4008): #04 pc 00058c70 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
03-03 02:02:39.054: I/DEBUG(4008): code around pc:
03-03 02:02:39.054: I/DEBUG(4008): 402d0160 0003151e 4604b570 f7ff460d 4620ff81 ....p..F.F.... F
03-03 02:02:39.054: I/DEBUG(4008): 402d0170 f7ff4629 bd70ff93 4604b570 460e6800 )F....p.p..F.h.F
03-03 02:02:39.054: I/DEBUG(4008): 402d0180 68834615 dd062b40 21fa4810 44784a10 .F.h@+...H.!.JxD
03-03 02:02:39.054: I/DEBUG(4008): 402d0190 f7c8447a 6821f80f 698a4620 47904631 zD....!h F.i1F.G
03-03 02:02:39.054: I/DEBUG(4008): 402d01a0 b1154606 68836820 6822602b b12b6a13 .F.. h.h+`"h.j+.
03-03 02:02:39.054: I/DEBUG(4008): code around lr:
03-03 02:02:39.054: I/DEBUG(4008): 402d01bc 68e06821 21006c4a ea0af7c4 bd704630 !h.hJl.!....0Fp.
03-03 02:02:39.054: I/DEBUG(4008): 402d01cc 00031492 000314b5 4604b570 ffcef7ff ........p..F....
03-03 02:02:39.054: I/DEBUG(4008): 402d01dc 46204605 ff12f7ff bd704628 4604b573 .F F....(Fp.s..F
03-03 02:02:39.054: I/DEBUG(4008): 402d01ec 2102460d fb36f002 42ab6823 b123d020 .F.!..6.#h.B .#.
03-03 02:02:39.054: I/DEBUG(4008): 402d01fc b1136c5b f7c868e0 68a0fccf 05c26025 [l...h.....h%`..
03-03 02:02:39.054: I/DEBUG(4008): memory map around addr 68f52abc:
03-03 02:02:39.054: I/DEBUG(4008): 4d8c5000-4d9c4000
03-03 02:02:39.054: I/DEBUG(4008): (no map for address)
03-03 02:02:39.054: I/DEBUG(4008): b0001000-b0009000 /system/bin/linker
03-03 02:02:39.054: I/DEBUG(4008): stack:
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b88 408d1f90 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b8c 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b90 00000001
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b94 408d6c58 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b98 408d6fa8 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b9c 4c479dec
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba0 46cf260a /system/framework/core.odex
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba4 408735e7 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba8 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bac 002bf070 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb0 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb4 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb8 412ef268 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bbc 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc0 df0027ad
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc4 00000000
03-03 02:02:39.054: I/DEBUG(4008): #00 4d9c3bc8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bcc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd4 402d01dd /system/lib/libcrypto.so
03-03 02:02:39.054: I/DEBUG(4008): #01 4d9c3bd8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bdc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be4 4024e817 /system/lib/libnativehelper.so
03-03 02:02:39.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:39.500: D/CommService(7477): Monitoring nodes...
03-03 02:02:39.500: D/dalvikvm(7477): GC_FOR_ALLOC freed 2073K, 16% free 17118K/20359K, paused 51ms
03-03 02:02:39.632: D/dalvikvm(7477): GC_CONCURRENT freed 1998K, 16% free 17162K/20359K, paused 2ms+4ms
03-03 02:02:40.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:40.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:40.562: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17158K/20359K, paused 3ms+4ms
03-03 02:02:41.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:41.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:41.531: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17154K/20359K, paused 3ms+12ms
03-03 02:02:42.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:42.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:42.507: D/dalvikvm(7477): GC_CONCURRENT freed 2068K, 16% free 17128K/20359K, paused 3ms+4ms
03-03 02:02:42.679: D/dalvikvm(7477): GC_CONCURRENT freed 2006K, 16% free 17161K/20359K, paused 2ms+12ms
03-03 02:02:43.140: I/BootReceiver(1236): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
03-03 02:02:43.210: D/dalvikvm(1236): GC_FOR_ALLOC freed 912K, 17% free 10207K/12295K, paused 62ms
03-03 02:02:43.265: D/dalvikvm(1236): GC_FOR_ALLOC freed 243K, 16% free 10374K/12295K, paused 49ms
03-03 02:02:43.265: I/dalvikvm-heap(1236): Grow heap (frag case) to 10.507MB for 196628-byte allocation
I need to catch segmentation fault in third party library cleanup operations. This happens sometimes just before my program exits, and I cannot fix the real reason of this. In Windows programming I could do this with __try - __catch. Is there cross-platform or platform-specific way to do the same? I need this in Linux, gcc.
Interpreting segfault messagesWhat is the correct interpretation of the following segfault messages?
segfault at 10 ip 00007f9bebcca90d sp 00007fffb62705f0 error 4 in libQtWebKit.so.4.5.2[7f9beb83a000+f6f000]
segfault at 10 ip 00007fa44d78890d sp 00007fff43f6b720 error 4 in libQtWebKit.so.4.5.2[7fa44d2f8000+f6f000]
segfault at 11 ip 00007f2b0022acee sp 00007fff368ea610 error 4 in libQtWebKit.so.4.5.2[7f2aff9f7000+f6f000]
segfault at 11 ip 00007f24b21adcee sp 00007fff7379ded0 error 4 in libQtWebKit.so.4.5.2[7f24b197a000+f6f000]
How can I debug a Python segmentation fault?
We are trying to run our python code on SuSE 12.3. We get reproducible segmentation faults. The python code has been working on other platforms without segmentation faults, for years.
We only code Python, no C extension ....
What is the best way to debug this? I know a bit ansi c, but that was ten years ago ....
Python 2.7.5
Update
The segmentation fault happens on interpreter shutdown.
I can run the script several times:
python -m pdb myscript.py arg1 arg1
continue
run
continue
run
But the segmentation faults happen, if I leave the pdb with ctrl-d.
Update 2
I now try to debug it with gdb:
gdb
> file python
> run myscript.py arg1 arg2
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffefbe2700 (LWP 15483)]
0x00007ffff7aef93c in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
(gdb) bt
#0 0x00007ffff7aef93c in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#1 0x00007ffff7af5303 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#2 0x00007ffff7adc858 in ?? () from /usr/lib64/libpython2.7.so.1.0
#3 0x00007ffff7ad840d in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#4 0x00007ffff7af1082 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#5 0x00007ffff7af233d in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#6 0x00007ffff7af233d in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#7 0x00007ffff7af5303 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#8 0x00007ffff7adc5b6 in ?? () from /usr/lib64/libpython2.7.so.1.0
#9 0x00007ffff7ad840d in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007ffff7ad9171 in ?? () from /usr/lib64/libpython2.7.so.1.0
#11 0x00007ffff7ad840d in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#12 0x00007ffff7aeeb62 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0
#13 0x00007ffff7acc757 in ?? () from /usr/lib64/libpython2.7.so.1.0
#14 0x00007ffff7828e0f in start_thread () from /lib64/libpthread.so.0
#15 0x00007ffff755c7dd in clone () from /lib64/libc.so.6
Update 3
I installed gdbinit from http://hg.python.org/cpython/file/default/Misc/gdbinit and the debugging symbols from http://download.opensuse.org/debug/distribution/12.3/repo/oss/suse/x86_64/
(gdb) pystack
No symbol "_PyUnicode_AsString" in current context.
What now?
Update 4 We installed the a new RPM (python-2.7.5-3.1.x86_64). We get less segfaults, but they still happen. Here is the link to repository:
http://download.opensuse.org/repositories/devel:/languages:/python:/Factory/openSUSE_12.3/x86_64/
Update 5 Solved my initial problem:
It was http://bugs.python.org/issue1856 (shutdown (exit) can hang or segfault with daemon threads running)
Related: Detect Interpreter shut down in daemon thread
Segmentation fault at glGenVertexArrays( 1, &vao );My gdb backtrace gives:
(gdb) backtrace
#0 0x00000000 in ?? ()
#1 0x0804a211 in init () at example1.cpp:147
#2 0x0804a6bc in main (argc=1, argv=0xbffff3d4) at example1.cpp:283
Not very informative. Eclipse debugger at least lets me see that it stops on line 3 below:
// Create a vertex array object
GLuint vao;
glGenVertexArrays( 1, &vao );
glBindVertexArray( vao );
This is a very common block to see in gl programming, and I'm even running other code with the same block with no problem. So I'm baffled.
Build output from running make:
g++ -g -DFREEGLUT_STATIC -DGLEW_STATIC -I../../include example1.cpp ../../Commo/InitShader.o -L/usr/lib/mesa -lGLEW -lglut -lGL -lX11 -lm -o example1
Program containing the problem:
// rotating cube with two texture objects
// change textures with 1 and 2 keys
#include "Angel.h"
const int NumTriangles = 12; // (6 faces)(2 triangles/face)
const int NumVertices = 3 * NumTriangles;
const int TextureSize = 64;
typedef Angel::vec4 point4;
typedef Angel::vec4 color4;
// Texture objects and storage for texture image
GLuint textures[2];
GLubyte image[TextureSize][TextureSize][3];
GLubyte image2[TextureSize][TextureSize][3];
// Vertex data arrays
point4 points[NumVertices];
color4 quad_colors[NumVertices];
vec2 tex_coords[NumVertices];
// Array of rotation angles (in degrees) for each coordinate axis
enum { Xaxis = 0, Yaxis = 1, Zaxis = 2, NumAxes = 3 };
int Axis = Xaxis;
GLfloat Theta[NumAxes] = { 0.0, 0.0, 0.0 };
GLuint theta;
//----------------------------------------------------------------------------
int Index = 0;
void quad( int a, int b, int c, int d )
{
point4 vertices[8] = {
point4( -0.5, -0.5, 0.5, 1.0 ),
point4( -0.5, 0.5, 0.5, 1.0 ),
point4( 0.5, 0.5, 0.5, 1.0 ),
point4( 0.5, -0.5, 0.5, 1.0 ),
point4( -0.5, -0.5, -0.5, 1.0 ),
point4( -0.5, 0.5, -0.5, 1.0 ),
point4( 0.5, 0.5, -0.5, 1.0 ),
point4( 0.5, -0.5, -0.5, 1.0 )
};
color4 colors[8] = {
color4( 0.0, 0.0, 0.0, 1.0 ), // black
color4( 1.0, 0.0, 0.0, 1.0 ), // red
color4( 1.0, 1.0, 0.0, 1.0 ), // yellow
color4( 0.0, 1.0, 0.0, 1.0 ), // green
color4( 0.0, 0.0, 1.0, 1.0 ), // blue
color4( 1.0, 0.0, 1.0, 1.0 ), // magenta
color4( 0.0, 1.0, 1.0, 1.0 ), // white
color4( 1.0, 1.0, 1.0, 1.0 ) // cyan
};
quad_colors[Index] = colors[a];
points[Index] = vertices[a];
tex_coords[Index] = vec2( 0.0, 0.0 );
Index++;
quad_colors[Index] = colors[a];
points[Index] = vertices[b];
tex_coords[Index] = vec2( 0.0, 1.0 );
Index++;
quad_colors[Index] = colors[a];
points[Index] = vertices[c];
tex_coords[Index] = vec2( 1.0, 1.0 );
Index++;
quad_colors[Index] = colors[a];
points[Index] = vertices[a];
tex_coords[Index] = vec2( 0.0, 0.0 );
Index++;
quad_colors[Index] = colors[a];
points[Index] = vertices[c];
tex_coords[Index] = vec2( 1.0, 1.0 );
Index++;
quad_colors[Index] = colors[a];
points[Index] = vertices[d];
tex_coords[Index] = vec2( 1.0, 0.0 );
Index++;
}
//----------------------------------------------------------------------------
void colorcube()
{
quad( 1, 0, 3, 2 );
quad( 2, 3, 7, 6 );
quad( 3, 0, 4, 7 );
quad( 6, 5, 1, 2 );
quad( 4, 5, 6, 7 );
quad( 5, 4, 0, 1 );
}
//----------------------------------------------------------------------------
void init()
{
colorcube();
// Create a checkerboard pattern
for ( int i = 0; i < 64; i++ ) {
for ( int j = 0; j < 64; j++ ) {
GLubyte c = (((i & 0x8) == 0) ^ ((j & 0x8) == 0)) * 255;
image[i][j][0] = c;
image[i][j][1] = c;
image[i][j][2] = c;
image2[i][j][0] = c;
image2[i][j][1] = 0;
image2[i][j][2] = c;
}
}
// Initialize texture objects
glGenTextures( 2, textures );
glBindTexture( GL_TEXTURE_2D, textures[0] );
glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB, TextureSize, TextureSize, 0,
GL_RGB, GL_UNSIGNED_BYTE, image );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
glBindTexture( GL_TEXTURE_2D, textures[1] );
glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB, TextureSize, TextureSize, 0,
GL_RGB, GL_UNSIGNED_BYTE, image2 );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
glActiveTexture( GL_TEXTURE0 );
glBindTexture( GL_TEXTURE_2D, textures[0] );
// Create a vertex array object
GLuint vao;
glGenVertexArrays( 1, &vao );
glBindVertexArray( vao );
// Create and initialize a buffer object
GLuint buffer;
glGenBuffers( 1, &buffer );
glBindBuffer( GL_ARRAY_BUFFER, buffer );
glBufferData( GL_ARRAY_BUFFER,
sizeof(points) + sizeof(quad_colors) + sizeof(tex_coords),
NULL, GL_STATIC_DRAW );
// Specify an offset to keep track of where we're placing data in our
// vertex array buffer. We'll use the same technique when we
// associate the offsets with vertex attribute pointers.
GLintptr offset = 0;
glBufferSubData( GL_ARRAY_BUFFER, offset, sizeof(points), points );
offset += sizeof(points);
glBufferSubData( GL_ARRAY_BUFFER, offset,
sizeof(quad_colors), quad_colors );
offset += sizeof(quad_colors);
glBufferSubData( GL_ARRAY_BUFFER, offset, sizeof(tex_coords), tex_coords );
// Load shaders and use the resulting shader program
GLuint program = InitShader( "vshader71.glsl", "fshader71.glsl" );
glUseProgram( program );
// set up vertex arrays
offset = 0;
GLuint vPosition = glGetAttribLocation( program, "vPosition" );
glEnableVertexAttribArray( vPosition );
glVertexAttribPointer( vPosition, 4, GL_FLOAT, GL_FALSE, 0,
BUFFER_OFFSET(offset) );
offset += sizeof(points);
GLuint vColor = glGetAttribLocation( program, "vColor" );
glEnableVertexAttribArray( vColor );
glVertexAttribPointer( vColor, 4, GL_FLOAT, GL_FALSE, 0,
BUFFER_OFFSET(offset) );
offset += sizeof(quad_colors);
GLuint vTexCoord = glGetAttribLocation( program, "vTexCoord" );
glEnableVertexAttribArray( vTexCoord );
glVertexAttribPointer( vTexCoord, 2, GL_FLOAT, GL_FALSE, 0,
BUFFER_OFFSET(offset) );
// Set the value of the fragment shader texture sampler variable
// ("texture") to the the appropriate texture unit. In this case,
// zero, for GL_TEXTURE0 which was previously set by calling
// glActiveTexture().
glUniform1i( glGetUniformLocation(program, "texture"), 0 );
theta = glGetUniformLocation( program, "theta" );
glEnable( GL_DEPTH_TEST );
glClearColor( 1.0, 1.0, 1.0, 1.0 );
}
void display( void )
{
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glUniform3fv( theta, 1, Theta );
glDrawArrays( GL_TRIANGLES, 0, NumVertices );
glutSwapBuffers();
}
//----------------------------------------------------------------------------
void mouse( int button, int state, int x, int y )
{
if ( state == GLUT_DOWN ) {
switch( button ) {
case GLUT_LEFT_BUTTON: Axis = Xaxis; break;
case GLUT_MIDDLE_BUTTON: Axis = Yaxis; break;
case GLUT_RIGHT_BUTTON: Axis = Zaxis; break;
}
}
}
//----------------------------------------------------------------------------
void idle( void )
{
Theta[Axis] += 0.01;
if ( Theta[Axis] > 360.0 ) {
Theta[Axis] -= 360.0;
}
glutPostRedisplay();
}
//----------------------------------------------------------------------------
void keyboard( unsigned char key, int mousex, int mousey )
{
switch( key ) {
case 033: // Escape Key
case 'q': case 'Q':
exit( EXIT_SUCCESS );
break;
case '1':
glBindTexture( GL_TEXTURE_2D, textures[0] );
break;
case '2':
glBindTexture( GL_TEXTURE_2D, textures[1] );
break;
}
glutPostRedisplay();
}
//----------------------------------------------------------------------------
int main( int argc, char **argv )
{
glutInit( &argc, argv );
glutInitDisplayMode( GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH );
glutInitWindowSize( 512, 512 );
glutInitContextVersion( 3, 2 );
glutInitContextProfile( GLUT_CORE_PROFILE );
glutCreateWindow( "Color Cube" );
glewInit();
init();
glutDisplayFunc( display );
glutKeyboardFunc( keyboard );
glutMouseFunc( mouse );
glutIdleFunc( idle );
glutMainLoop();
return 0;
}
Following a previous question of mine, most comments say "just don't, you are in a limbo state, you have to kill everything and start over". There is also a "safeish" workaround.
What I fail to understand is why a segmentation fault is inherently nonrecoverable.
The moment in which writing to protected memory is caught - otherwise, the SIGSEGV would not be sent.
If the moment of writing to protected memory can be caught, I don't see why - in theory - it can't be reverted, at some low level, and have the SIGSEGV converted to a standard software exception.
Please explain why after a segmentation fault the program is in an undetermined state, as very obviously, the fault is thrown before memory was actually changed (I am probably wrong and don't see why). Had it been thrown after, one could create a program that changes protected memory, one byte at a time, getting segmentation faults, and eventually reprogramming the kernel - a security risk that is not present, as we can see the world still stands.
SIGSEGV sent)?I am implementing Kosaraju's Strong Connected Component(SCC) graph search algorithm in Python.
The program runs great on small data set, but when I run it on a super-large graph (more than 800,000 nodes), it says "Segmentation Fault".
What might be the cause of it? Thank you!
Additional Info: First I got this Error when running on the super-large data set:
"RuntimeError: maximum recursion depth exceeded in cmp"
Then I reset the recursion limit using
sys.setrecursionlimit(50000)
but got a 'Segmentation fault'
Believe me it's not a infinite loop, it runs correct on relatively smaller data. It is possible the program exhausted the resources?
What is SEGV_MAPERR?What is SEGV_MAPERR, why does it always come up with SIGSEGV?
I think the question says it all. An example covering most standards from C89 to C11 would be helpful. I though of this one, but I guess it is just undefined behaviour:
#include <stdio.h>
int main( int argc, char* argv[] )
{
const char *s = NULL;
printf( "%c\n", s[0] );
return 0;
}
EDIT:
As some votes requested clarification: I wanted to have a program with an usual programming error (the simplest I could think of was an segfault), that is guaranteed (by standard) to abort. This is a bit different to the minimal segfault question, which don't care about this insurance.
What is a bus error? Is it different from a segmentation fault?What does the "bus error" message mean, and how does it differ from a segmentation fault?
Compile and run program without main() in CI'm trying to compile and run following program without main() function in C. I have compiled my program using the following command.
gcc -nostartfiles nomain.c
And compiler gives warning
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400340
Ok, No problem. then, I have run executable file(a.out), both printf statements print successfully, and then get segmentation fault.
So, my question is, Why segmentation fault after successfully execute print statements?
my code:
#include <stdio.h>
void nomain()
{
printf("Hello World...\n");
printf("Successfully run without main...\n");
}
output:
Hello World...
Successfully run without main...
Segmentation fault (core dumped)
Note:
Here, -nostartfiles gcc flag prevents the compiler from using standard startup files when linking
I have a multithreaded C program, which consistently generates a segmentation fault at a specific point in the program. When I run it with gdb, no fault is shown. Can you think of any reason why the fault might occur only when not using the debugger? It's pretty annoying not being able to use it to find the problem!
Line number of segmentation faultIs there any gcc option I can set that will give me the line number of the segmentation fault?
I know I can:
Edits:
bt / where on gdb give No stack.I am writing a cross-platform C++ program for Windows and Unix. On the Window side, the code will compile and execute no problem. On the Unix side, it will compile however when I try to run it, I get a segmentation fault. My initial hunch is that there is a problem with pointers.
What are good methodologies to find and fix segmentation fault errors?
"Unexplainable" core dumpI've seen many core dumps in my life, but this one has me stumped.
Context:
Here are the details of the crash:
Program terminated with signal 11, Segmentation fault.
#0 0x00000000017bd9fd in Foo()
(gdb) x/i $pc
=> 0x17bd9fd <_Z3Foov+349>: rex.RB orb $0x8d,(%r15)
(gdb) x/6i $pc-12
0x17bd9f1 <_Z3Foov+337>: mov (%rbx),%eax
0x17bd9f3 <_Z3Foov+339>: mov %rbx,%rdi
0x17bd9f6 <_Z3Foov+342>: callq *0x70(%rax)
0x17bd9f9 <_Z3Foov+345>: cmp %eax,%r12d
0x17bd9fc <_Z3Foov+348>: mov %eax,-0x80(%rbp)
0x17bd9ff <_Z3Foov+351>: jge 0x17bd97e <_Z3Foov+222>
You'll notice that the crash happened in the middle of instruction at 0x17bd9fc, which is after return from a call at 0x17bd9f6 to a virtual function.
When I examine the virtual table, I see that it is not corrupted in any way:
(gdb) x/a $rbx
0x2ab094951f80: 0x3f8c550 <_ZTI4Foo1+16>
(gdb) x/a 0x3f8c550+0x70
0x3f8c5c0 <_ZTI4Foo1+128>: 0x2d3d7b0 <_ZN4Foo13GetEv>
and that it points to this trivial function (as expected by looking at the source):
(gdb) disas 0x2d3d7b0
Dump of assembler code for function _ZN4Foo13GetEv:
0x0000000002d3d7b0 <+0>: push %rbp
0x0000000002d3d7b1 <+1>: mov 0x70(%rdi),%eax
0x0000000002d3d7b4 <+4>: mov %rsp,%rbp
0x0000000002d3d7b7 <+7>: leaveq
0x0000000002d3d7b8 <+8>: retq
End of assembler dump.
Further, when I look at the return address that Foo1::Get() should have returned to:
(gdb) x/a $rsp-8
0x2afa55602048: 0x17bd9f9 <_Z3Foov+345>
I see that it points to the right instruction, so it's as if during the return from Foo1::Get(), some gremlin came along and incremented %rip by 4.
Plausible explanations?
Why does this code segfault on 64-bit architecture but work fine on 32-bit?I came across the following C puzzle:
Q: Why does the following program segfault on IA-64, but work fine on IA-32?
int main()
{
int* p;
p = (int*)malloc(sizeof(int));
*p = 10;
return 0;
}
I know that the size of int on a 64 bit machine may not be the same as the size of a pointer (int could be 32 bits and pointer could be 64 bits). But I am not sure how this relates to the above program.
Any ideas?
I'm trying to execute a Python script, but I am getting the following error:
Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)
I'm using python 3.5.2 on a Linux Mint 18.1 Serena OS
Can someone tell me why this happens, and how can I solve?
What is a segmentation fault?What is a segmentation fault? Is it different in C and C++? How are segmentation faults and dangling pointers related?
Why is this RMagick call generating a segmentation fault?I've been banging my head against the wall for the better part of an hour trying to figure out what's going wrong here, and I'm sure (or rather hoping) it's something fairly obvious that I'm overlooking. I'm using Ruby 1.9.1, Sinatra 1.0, and RMagick 2.13.1. ImageMagick and RMagick are correctly installed and functional—I've successfully manipulated and saved images from irb.
The relevant part of the params array (formatting changes for the sake of readability):
{"admin_user_new_image_file"=>
{
:filename=>"freddie-on-shetland-pony.png",
:type=>"image/png",
:name=>"admin_user_new_image_file",
:tempfile=>#<File:/var/folders/a7/a7pO5jMcGLCww9XBGRvWfE+++TI/-Tmp-/RackMultipart20100514-20700-o2tkqu-0>,
:head=>"Content-Disposition: form-data; name=\"admin_user_new_image_file\"; filename=\"freddie-on-shetland-pony.png\"\r\nContent-Type: image/png\r\n"
}
}
The relevant code:
post "/admin/user/:account_name/image/new/" do
if params[:admin_user_new_image_file][:tempfile]
thumbnail = Magick::Image.read("png:"+params[:admin_user_new_image_file][:tempfile].path).first
end
end
The error (line 229 is the line starting with "thumbnail = ":
config.ru:229: [BUG] Segmentation fault
ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-darwin10.3.0]
-- control frame ----------
c:0042 p:---- s:0196 b:0196 l:000195 d:000195 CFUNC :read
c:0041 p:0121 s:0192 b:0192 l:001ab8 d:000191 LAMBDA config.ru:229
c:0040 p:---- s:0189 b:0189 l:000188 d:000188 FINISH
c:0039 p:---- s:0187 b:0187 l:000186 d:000186 CFUNC :call
c:0038 p:0018 s:0184 b:0184 l:001d78 d:000183 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:865
c:0037 p:---- s:0182 b:0182 l:000181 d:000181 FINISH
c:0036 p:---- s:0180 b:0180 l:000179 d:000179 CFUNC :instance_eval
c:0035 p:0016 s:0177 b:0175 l:000174 d:000174 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:521
c:0034 p:0024 s:0171 b:0171 l:000148 d:000170 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:500
c:0033 p:---- s:0169 b:0169 l:000168 d:000168 FINISH
c:0032 p:---- s:0167 b:0167 l:000166 d:000166 CFUNC :catch
c:0031 p:0140 s:0163 b:0163 l:000148 d:000162 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:497
c:0030 p:---- s:0154 b:0154 l:000153 d:000153 FINISH
c:0029 p:---- s:0152 b:0152 l:000151 d:000151 CFUNC :each
c:0028 p:0073 s:0149 b:0149 l:000148 d:000148 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:476
c:0027 p:0076 s:0141 b:0141 l:000140 d:000140 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:601
c:0026 p:0009 s:0137 b:0137 l:000138 d:000136 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411
c:0025 p:---- s:0135 b:0135 l:000134 d:000134 FINISH
c:0024 p:---- s:0133 b:0133 l:000132 d:000132 CFUNC :instance_eval
c:0023 p:0012 s:0130 b:0130 l:000121 d:000129 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566
c:0022 p:---- s:0128 b:0128 l:000127 d:000127 FINISH
c:0021 p:---- s:0126 b:0126 l:000125 d:000125 CFUNC :catch
c:0020 p:0013 s:0122 b:0122 l:000121 d:000121 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566
c:0019 p:0098 s:0115 b:0115 l:000138 d:000138 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411
c:0018 p:0019 s:0108 b:0108 l:000107 d:000107 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:399
c:0017 p:0014 s:0104 b:0104 l:000103 d:000103 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/showexceptions.rb:24
c:0016 p:0150 s:0098 b:0098 l:000097 d:000097 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/methodoverride.rb:24
c:0015 p:0031 s:0092 b:0092 l:000091 d:000091 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/commonlogger.rb:18
c:0014 p:0018 s:0084 b:0084 l:002080 d:000083 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979
c:0013 p:0032 s:0082 b:0082 l:000081 d:000081 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:1005
c:0012 p:0011 s:0078 b:0078 l:002080 d:002080 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979
c:0011 p:0100 s:0074 b:0074 l:000ff0 d:000ff0 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/lint.rb:47
c:0010 p:0022 s:0068 b:0068 l:000067 d:000067 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/lint.rb:35
c:0009 p:0014 s:0064 b:0064 l:000063 d:000063 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/showexceptions.rb:24
c:0008 p:0031 s:0058 b:0058 l:000057 d:000057 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/commonlogger.rb:18
c:0007 p:0014 s:0050 b:0050 l:000049 d:000049 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/content_length.rb:13
c:0006 p:0320 s:0042 b:0042 l:000041 d:000041 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/handler/webrick.rb:48
c:0005 p:0256 s:0030 b:0030 l:000029 d:000029 METHOD /usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:111
c:0004 p:0382 s:0020 b:0020 l:000019 d:000019 METHOD /usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:70
c:0003 p:0123 s:0009 b:0009 l:000bc8 d:000008 BLOCK /usr/local/lib/ruby/1.9.1/webrick/server.rb:183
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:---- s:0002 b:0002 l:000001 d:000001 TOP
---------------------------
-- Ruby level backtrace information-----------------------------------------
config.ru:229:in `read'
config.ru:229:in `block (2 levels) in <main>'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:865:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:865:in `block in route'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `instance_eval'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:521:in `route_eval'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:500:in `block (2 levels) in route!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `catch'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:497:in `block in route!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `each'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:476:in `route!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:601:in `dispatch!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `block in call!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `instance_eval'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `block in invoke'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `catch'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `invoke'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `call!'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:399:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/showexceptions.rb:24:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/methodoverride.rb:24:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/commonlogger.rb:18:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `block in call'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:1005:in `synchronize'
/usr/local/lib/ruby/gems/1.9.1/gems/sinatra-1.0/lib/sinatra/base.rb:979:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/lint.rb:47:in `_call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/lint.rb:35:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/showexceptions.rb:24:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/commonlogger.rb:18:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/content_length.rb:13:in `call'
/usr/local/lib/ruby/gems/1.9.1/gems/rack-1.1.0/lib/rack/handler/webrick.rb:48:in `service'
/usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
/usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
/usr/local/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
-- C level backtrace information -------------------------------------------
0x10010cd8d 0 libruby.dylib 0x000000010010cd8d rb_vm_bugreport + 77
0x10002b184 1 libruby.dylib 0x000000010002b184 report_bug + 260
0x10002b318 2 libruby.dylib 0x000000010002b318 rb_bug + 200
0x1000b7124 3 libruby.dylib 0x00000001000b7124 sigsegv + 132
0x7fff8301c80a 4 libSystem.B.dylib 0x00007fff8301c80a _sigtramp + 26
0x1032313ac 5 libMagickCore.3.dylib 0x00000001032313ac Splay + 300
0x103119245 6 libMagickCore.3.dylib 0x0000000103119245 AcquirePixelCache + 325
0x1031cb317 7 libMagickCore.3.dylib 0x00000001031cb317 AcquireImage + 375
0x10333035b 8 libMagickCore.3.dylib 0x000000010333035b ReadPNGImage + 155
0x1031418fd 9 libMagickCore.3.dylib 0x00000001031418fd ReadImage + 2221
0x101f1b72b 10 RMagick2.bundle 0x0000000101f1b72b rd_image + 339
0x101f1b59b 11 RMagick2.bundle 0x0000000101f1b59b Image_read + 36
0x1000fd0e4 12 libruby.dylib 0x00000001000fd0e4 vm_call_cfunc + 340
0x1000fe9b0 13 libruby.dylib 0x00000001000fe9b0 vm_call_method + 896
0x1000ff8fc 14 libruby.dylib 0x00000001000ff8fc vm_exec_core + 3180
0x100104b93 15 libruby.dylib 0x0000000100104b93 vm_exec + 1203
0x100106643 16 libruby.dylib 0x0000000100106643 rb_vm_invoke_proc + 691
0x100106ccd 17 libruby.dylib 0x0000000100106ccd vm_call0 + 1085
0x1000317c6 18 libruby.dylib 0x00000001000317c6 rb_method_call + 406
0x1000fd0e4 19 libruby.dylib 0x00000001000fd0e4 vm_call_cfunc + 340
0x1000fe9b0 20 libruby.dylib 0x00000001000fe9b0 vm_call_method + 896
0x1000ff8fc 21 libruby.dylib 0x00000001000ff8fc vm_exec_core + 3180
0x100104b93 22 libruby.dylib 0x0000000100104b93 vm_exec + 1203
0x100105ce6 23 libruby.dylib 0x0000000100105ce6 yield_under + 710
0x100106188 24 libruby.dylib 0x0000000100106188 specific_eval + 72
0x1000fd0e4 25 libruby.dylib 0x00000001000fd0e4 vm_call_cfunc + 340
0x1000fe9b0 26 libruby.dylib 0x00000001000fe9b0 vm_call_method + 896
0x1000ff8fc 27 libruby.dylib 0x00000001000ff8fc vm_exec_core + 3180
0x100104b93 28 libruby.dylib 0x0000000100104b93 vm_exec + 1203
0x10010b6bf 29 libruby.dylib 0x000000010010b6bf rb_f_catch + 639
0x1000fd0e4 30 libruby.dylib 0x00000001000fd0e4 vm_call_cfunc + 340
0x1000fe9b0 31 libruby.dylib 0x00000001000fe9b0 vm_call_method + 896
0x1000ff8fc 32 libruby.dylib 0x00000001000ff8fc vm_exec_core + 3180
0x100104b93 33 libruby.dylib 0x0000000100104b93 vm_exec + 1203
0x10010aac9 34 libruby.dylib 0x000000010010aac9 rb_yield + 505
0x100007902 35 libruby.dylib 0x0000000100007902 rb_ary_each + 82
0x1000fd0e4 36 libruby.dylib 0x00000001000fd0e4 vm_call_cfunc + 340
0x1000fe9b0 37 libruby.dylib 0x00000001000fe9b0 vm_call_method + 896
0x1000ff8fc 38 libruby.dylib 0x00000001000ff8fc vm_exec_core + 3180
0x100104b93 39 libruby.dylib 0x0000000100104b93 vm_exec + 1203
0x100105ce6 40 libruby.dylib 0x0000000100105ce6 yield_under + 710
0x100106188 41 libruby.dylib 0x0000000100106188 specific_eval + 72
0x1000fd0e4 42 libruby.dylib 0x00000001000fd0e4 vm_call_cfunc + 340
0x1000fe9b0 43 libruby.dylib 0x00000001000fe9b0 vm_call_method + 896
0x1000ff8fc 44 libruby.dylib 0x00000001000ff8fc vm_exec_core + 3180
0x100104b93 45 libruby.dylib 0x0000000100104b93 vm_exec + 1203
0x10010b6bf 46 libruby.dylib 0x000000010010b6bf rb_f_catch + 639
0x1000fd0e4 47 libruby.dylib 0x00000001000fd0e4 vm_call_cfunc + 340
0x1000fe9b0 48 libruby.dylib 0x00000001000fe9b0 vm_call_method + 896
0x1000ff8fc 49 libruby.dylib 0x00000001000ff8fc vm_exec_core + 3180
0x100104b93 50 libruby.dylib 0x0000000100104b93 vm_exec + 1203
0x100106643 51 libruby.dylib 0x0000000100106643 rb_vm_invoke_proc + 691
0x100111803 52 libruby.dylib 0x0000000100111803 thread_start_func_2 + 835
0x100111921 53 libruby.dylib 0x0000000100111921 thread_start_func_1 + 17
0x7fff82ff58b6 54 libSystem.B.dylib 0x00007fff82ff58b6 _pthread_start + 331
0x7fff82ff5769 55 libSystem.B.dylib 0x00007fff82ff5769 thread_start + 13
[NOTE]
You may encounter a bug of Ruby interpreter. Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
Abort trap
Anyone have any idea what's going on? Thanks!
How can I catch SIGSEGV (segmentation fault) and get a stack trace under JNI on Android?I'm moving a project to the new Android Native Development Kit (i.e. JNI) and I'd like to catch SIGSEGV, should it occur (possibly also SIGILL, SIGABRT, SIGFPE) in order to present a nice crash reporting dialog, instead of (or before) what currently happens: the immediate unceremonious death of the process and possibly some attempt by the OS to restart it. (Edit: The JVM/Dalvik VM catches the signal and logs a stack trace and other useful information; I just want to offer the user the option to email that info to me really.)
The situation is: a large body of C code which I didn't write does most of the work in this application (all the game logic) and although it's well-tested on numerous other platforms, it's entirely possible that I, in my Android port, will feed it garbage and cause a crash in native code, so I want the crash dumps (both native and Java) that currently show up in the Android log (I guess it would be stderr in a non-Android situation). I'm free to modify both C and Java code arbitrarily, although the callbacks (both going in and coming out of JNI) number about 40 and obviously, bonus points for small diffs.
I've heard of the signal chaining library in J2SE, libjsig.so, and if I could safely install a signal handler like that on Android, that would solve the catching part of my question, but I see no such library for Android/Dalvik.
Command failed due to signal: Segmentation fault: 11I'm getting the error ...
Command failed due to signal: Segmentation fault: 11
... when trying to compile my Swift app. I'm using Xcode 6.1, trying to build for an iPhone 5 on iOS 8.1.
My Code
import UIKit
class ViewController: UIViewController {
@IBOutlet weak var username: UITextField!
@IBAction func signIn(sender: AnyObject) {
PFUser.logInWithUsernameInBackground(username.text, password:"mypass") {
(user: PFUser!, error: NSError!) -> Void in
if user != nil {
println("Logged In")
} else {
func myMethod() {
var user = PFUser()
user.username = username.text
user.password = " "
user.signUpInBackgroundWithBlock {
(succeeded: Bool!, error: NSError!) -> Void in
if error == nil {
// Hooray! Let them use the app now.
} else {
println("Signed Up")
}
}
}
println(error)
}
}
}
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
Parse.setApplicationId("key here")
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
// Dispose of any resources that can be recreated.
}
}
And the error text!
CompileSwift normal arm64 /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/ViewController.swift
cd /Users/Alec/Desktop/Re-Chat/Re-Chat
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -c -primary-file /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/ViewController.swift /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/AppDelegate.swift -target arm64-apple-ios8.0 -Xllvm -aarch64-use-tbi -target-cpu cyclone -target-abi darwinpcs -sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk -I /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Products/Debug-iphoneos -F /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Products/Debug-iphoneos -F /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat -g -import-objc-header /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/Re-Chat-Bridging-Header.h -module-cache-path /Users/Alec/Library/Developer/Xcode/DerivedData/ModuleCache -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/swift-overrides.hmap -Xcc -iquote -Xcc /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-generated-files.hmap -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-own-target-headers.hmap -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-all-target-headers.hmap -Xcc -iquote -Xcc /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-project-headers.hmap -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Products/Debug-iphoneos/include -Xcc -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/DerivedSources/arm64 -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/DerivedSources -Xcc -DDEBUG=1 -emit-module-doc-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController~partial.swiftdoc -Onone -module-name Re_Chat -emit-module-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController~partial.swiftmodule -serialize-diagnostics-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController.dia -emit-dependencies-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController.d -o /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController.o
0 swift 0x0000000108145a68 llvm::sys::PrintStackTrace(__sFILE*) + 40
1 swift 0x0000000108145f54 SignalHandler(int) + 452
2 libsystem_platform.dylib 0x00007fff86631f1a _sigtramp + 26
3 libsystem_platform.dylib 0x00007fd0ac1eb010 _sigtramp + 633049360
4 swift 0x00000001075d4517 swift::Lowering::SILGenFunction::emitClosureValue(swift::SILLocation, swift::SILDeclRef, llvm::ArrayRef<swift::Substitution>, swift::AnyFunctionRef) + 1303
5 swift 0x00000001075c599e swift::Lowering::SILGenFunction::visitFuncDecl(swift::FuncDecl*) + 190
6 swift 0x000000010760987c swift::Lowering::SILGenFunction::visitBraceStmt(swift::BraceStmt*) + 380
7 swift 0x000000010760c8e8 swift::ASTVisitor<swift::Lowering::SILGenFunction, void, void, void, void, void, void>::visit(swift::Stmt*) + 152
8 swift 0x000000010760a0a5 swift::Lowering::SILGenFunction::visitIfStmt(swift::IfStmt*) + 757
9 swift 0x000000010760c8f6 swift::ASTVisitor<swift::Lowering::SILGenFunction, void, void, void, void, void, void>::visit(swift::Stmt*) + 166
10 swift 0x00000001076097e8 swift::Lowering::SILGenFunction::visitBraceStmt(swift::BraceStmt*) + 232
11 swift 0x000000010760c8e8 swift::ASTVisitor<swift::Lowering::SILGenFunction, void, void, void, void, void, void>::visit(swift::Stmt*) + 152
12 swift 0x00000001075d52dd swift::Lowering::SILGenFunction::emitClosure(swift::AbstractClosureExpr*) + 205
13 swift 0x00000001075b4234 swift::Lowering::SILGenModule::emitClosure(swift::AbstractClosureExpr*) + 196
14 swift 0x00000001075eef71 (anonymous namespace)::RValueEmitter::visitAbstractClosureExpr(swift::AbstractClosureExpr*, swift::Lowering::SGFContext) + 97
15 swift 0x00000001075e1866 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 2870
16 swift 0x00000001075e24da swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 6058
17 swift 0x00000001075cfa0b swift::Lowering::SILGenFunction::emitExprInto(swift::Expr*, swift::Lowering::Initialization*) + 235
18 swift 0x00000001075ae824 swift::Lowering::RValueSource::materialize(swift::Lowering::SILGenFunction&) && + 196
19 swift 0x0000000107604a69 swift::Lowering::RValueSource::materialize(swift::Lowering::SILGenFunction&, swift::Lowering::AbstractionPattern, swift::SILType) && + 233
20 swift 0x00000001075f371c swift::Lowering::SILGenFunction::emitInjectOptionalValueInto(swift::SILLocation, swift::Lowering::RValueSource&&, swift::SILValue, swift::Lowering::TypeLowering const&) + 268
21 swift 0x00000001075e9b8d swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 36445
22 swift 0x00000001075e3e2b swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 12539
23 swift 0x00000001075e202b swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 4859
24 swift 0x00000001075cfab6 swift::Lowering::SILGenFunction::emitRValue(swift::Expr*, swift::Lowering::SGFContext) + 22
25 swift 0x00000001075bffc4 (anonymous namespace)::ArgEmitter::emitExpanded(swift::Lowering::RValueSource&&, swift::Lowering::AbstractionPattern) + 836
26 swift 0x00000001075bf582 (anonymous namespace)::ArgEmitter::emit(swift::Lowering::RValueSource&&, swift::Lowering::AbstractionPattern) + 98
27 swift 0x00000001075b7ff8 (anonymous namespace)::CallEmission::apply(swift::Lowering::SGFContext) + 1128
28 swift 0x00000001075b751a swift::Lowering::SILGenFunction::emitApplyExpr(swift::ApplyExpr*, swift::Lowering::SGFContext) + 58
29 swift 0x00000001075e0d81 swift::ASTVisitor<(anonymous namespace)::RValueEmitter, swift::Lowering::RValue, void, void, void, void, void, swift::Lowering::SGFContext>::visit(swift::Expr*, swift::Lowering::SGFContext) + 81
30 swift 0x00000001075ea00d swift::Lowering::SILGenFunction::emitIgnoredExpr(swift::Expr*) + 237
31 swift 0x0000000107609829 swift::Lowering::SILGenFunction::visitBraceStmt(swift::BraceStmt*) + 297
32 swift 0x000000010760c8e8 swift::ASTVisitor<swift::Lowering::SILGenFunction, void, void, void, void, void, void>::visit(swift::Stmt*) + 152
33 swift 0x00000001075d4ee0 swift::Lowering::SILGenFunction::emitFunction(swift::FuncDecl*) + 256
34 swift 0x00000001075b3659 swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*) + 233
35 swift 0x00000001075cea93 swift::ASTVisitor<SILGenType, void, void, void, void, void, void>::visit(swift::Decl*) + 355
36 swift 0x00000001075cd7eb SILGenType::emitType() + 203
37 swift 0x00000001075c85ae swift::Lowering::SILGenModule::visitNominalTypeDecl(swift::NominalTypeDecl*) + 30
38 swift 0x00000001075b555b swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, unsigned int) + 395
39 swift 0x00000001075b581a swift::SILModule::constructSIL(swift::Module*, swift::SourceFile*, swift::Optional<unsigned int>) + 314
40 swift 0x00000001075b5968 swift::performSILGeneration(swift::SourceFile&, swift::Optional<unsigned int>) + 72
41 swift 0x000000010748be18 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 3432
42 swift 0x000000010748996d main + 1677
43 libdyld.dylib 0x00007fff8aa4c5c9 start + 1
Stack dump:
0. Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -c -primary-file /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/ViewController.swift /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/AppDelegate.swift -target arm64-apple-ios8.0 -Xllvm -aarch64-use-tbi -target-cpu cyclone -target-abi darwinpcs -sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk -I /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Products/Debug-iphoneos -F /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Products/Debug-iphoneos -F /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat -g -import-objc-header /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/Re-Chat-Bridging-Header.h -module-cache-path /Users/Alec/Library/Developer/Xcode/DerivedData/ModuleCache -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/swift-overrides.hmap -Xcc -iquote -Xcc /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-generated-files.hmap -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-own-target-headers.hmap -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-all-target-headers.hmap -Xcc -iquote -Xcc /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Re-Chat-project-headers.hmap -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Products/Debug-iphoneos/include -Xcc -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/DerivedSources/arm64 -Xcc -I/Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/DerivedSources -Xcc -DDEBUG=1 -emit-module-doc-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController~partial.swiftdoc -Onone -module-name Re_Chat -emit-module-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController~partial.swiftmodule -serialize-diagnostics-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController.dia -emit-dependencies-path /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController.d -o /Users/Alec/Library/Developer/Xcode/DerivedData/Re-Chat-awwdkmqavitiqkcdsphwnhzhzzfb/Build/Intermediates/Re-Chat.build/Debug-iphoneos/Re-Chat.build/Objects-normal/arm64/ViewController.o
1. While emitting SIL for 'signIn' at /Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/ViewController.swift:14:15
2. While silgen closureexpr SIL function @_TFFC7Re_Chat14ViewController6signInFS0_FPSs9AnyObject_T_U_FTGSQCSo6PFUser_GSQCSo7NSError__T_ for expression at [/Users/Alec/Desktop/Re-Chat/Re-Chat/Re-Chat/ViewController.swift:16:80 - line:45:9] RangeText="{
(user: PFUser!, error: NSError!) -> Void in
if user != nil {
// Do stuff after successful login.
println("Logged In")
} else {
func myMethod() {
var user = PFUser()
user.username = username.text
user.password = ""
// other fields can be set just like with PFObject
user.signUpInBackgroundWithBlock {
(succeeded: Bool!, error: NSError!) -> Void in
if error == nil {
// Hooray! Let them use the app now.
} else {
println("Signed Up")
}
}
}
println("error")
}
}"
What is the root cause of the segmentation fault (SIGSEGV), and how to handle it?
Crash or "segmentation fault" when data is copied/scanned/read to an uninitialized pointerThis question is meant to be used as reference for all frequently asked questions of the nature:
Why do I get a mysterious crash or "segmentation fault" when I copy/scan data to the address where an uninitialised pointer points to?
For example:
char* ptr;
strcpy(ptr, "hello world"); // crash here!
or
char* ptr;
scanf("%s", ptr); // crash here!
I'm having a problem with some program, I have searched about segmentation faults, by I don't understand them quite well, the only thing I know is that presumably I am trying to access some memory I shouldn't. The problem is that I see my code and don't understand what I am doing wrong.
#include<stdio.h>
#include<math.h>
#include<stdlib.h>
#define lambda 2.0
#define g 1.0
#define Lx 100
#define F0 1.0
#define Tf 10
#define h 0.1
#define e 0.00001
FILE *file;
double F[1000][1000000];
void Inicio(double D[1000][1000000]) {
int i;
for (i=399; i<600; i++) {
D[i][0]=F0;
}
}
void Iteration (double A[1000][1000000]) {
long int i,k;
for (i=1; i<1000000; i++) {
A[0][i]= A[0][i-1] + e/(h*h*h*h)*g*g*(A[2][i-1] - 4.0*A[1][i-1] + 6.0*A[0][i-1]-4.0*A[998][i-1] + A[997][i-1]) + 2.0*g*e/(h*h)*(A[1][i-1] - 2*A[0][i-1] + A[998][i-1]) + e*A[0][i-1]*(lambda-A[0][i-1]*A[0][i-1]);
A[1][i]= A[1][i-1] + e/(h*h*h*h)*g*g*(A[3][i-1] - 4.0*A[2][i-1] + 6.0*A[1][i-1]-4.0*A[0][i-1] + A[998][i-1]) + 2.0*g*e/(h*h)*(A[2][i-1] - 2*A[1][i-1] + A[0][i-1]) + e*A[1][i-1]*(lambda-A[1][i-1]*A[1][i-1]);
for (k=2; k<997; k++) {
A[k][i]= A[k][i-1] + e/(h*h*h*h)*g*g*(A[k+2][i-1] - 4.0*A[k+1][i-1] + 6.0*A[k][i-1]-4.0*A[k-1][i-1] + A[k-2][i-1]) + 2.0*g*e/(h*h)*(A[k+1][i-1] - 2*A[k][i-1] + A[k-1][i-1]) + e*A[k][i-1]*(lambda-A[k][i-1]*A[k][i-1]);
}
A[997][i] = A[997][i-1] + e/(h*h*h*h)*g*g*(A[0][i-1] - 4*A[998][i-1] + 6*A[997][i-1] - 4*A[996][i-1] + A[995][i-1]) + 2.0*g*e/(h*h)*(A[998][i-1] - 2*A[997][i-1] + A[996][i-1]) + e*A[997][i-1]*(lambda-A[997][i-1]*A[997][i-1]);
A[998][i] = A[998][i-1] + e/(h*h*h*h)*g*g*(A[1][i-1] - 4*A[0][i-1] + 6*A[998][i-1] - 4*A[997][i-1] + A[996][i-1]) + 2.0*g*e/(h*h)*(A[0][i-1] - 2*A[998][i-1] + A[997][i-1]) + e*A[998][i-1]*(lambda-A[998][i-1]*A[998][i-1]);
A[999][i]=A[0][i];
}
}
main() {
long int i,j;
Inicio(F);
Iteration(F);
file = fopen("P1.txt","wt");
for (i=0; i<1000000; i++) {
for (j=0; j<1000; j++) {
fprintf(file,"%lf \t %.4f \t %lf\n", 1.0*j/10.0, 1.0*i, F[j][i]);
}
}
fclose(file);
}
Thanks for your time.
segmentation-fault