Skip to content

Does anyone know what this error is? (Segfault) … nevermind

Ok, I’m at the end of my sanity. I’m finally over the hell-death which is hand, foot and mouth (courtesy of my daughter) which means I can type again, and now I’m stuck trying to debug some dastardly segfault. Here is it (courtesy of /var/log/messages):


Jun 30 12:49:13 NON kernel: python[29965]: segfault at 000000010000000f rip
000000000044068e rsp 00002aabea0294b0 error 4

This is on a 64 bit machine. The application is heavily, heavily threaded python using queues for inter-thread communication, and the threads are using libcurl via pycurl under that.

I get no exceptions, no errors: Nothing. The interpreter simply dies. If I attach an strace to it, I see this:


futex(0x2e4a6300, FUTEX_WAKE, 1) = 0
futex(0x2e4a6300, FUTEX_WAKE, 1) = 0
futex(0x2aaaac10cab0, FUTEX_WAIT, 0, NULL) = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---

Any ideas?

Edit: Never mind, I finally found the answer… I removed:
curl.setopt(pycurl.CONNECTTIMEOUT, 120)
After reading this mail thread, and the code now flies. I love life.

  • anonymous
    Pure python code should *never* segfault! Every segfault should be considered a bug and get fixed.
  • Were you not able to run gdb? You can usually use it to get the stack trace of a segfault (using bt/backtrace). You have to load the Python binary with it though (and not your script), and then use "run /path/to/your/script arg1 arg2 ...".

    You can also change the user limit on core dumps so a full dump is produced on a segfault using "ulimit -c unlimited", and then load that core dump into gdb with "core core.123456".
  • Jesse, I'm not sure which I loathe more from my son. The winter set of colds, flus and viruses. Or the summer set of rashes, flus and viruses - of the gastrointestinal variation.

    I think summer.
blog comments powered by Disqus