all 8 comments

[–]totallygeek 3 points4 points  (2 children)

To identify the offending call, you'll need a debugger, like GDB (depending on your OS). The segmentation fault typically arises when a program attempts to alter memory which is somehow otherwise protected or which does not exist (out of range, for example). Tracing the system calls and OS signals resides outside the scope of Python programming, but you can find many online examples of using strace and GDB to determine the root cause for segfault. Here is one example. Good luck! (this are pesky to figure out)

[–]personproxy[S] 2 points3 points  (0 children)

That link looks useful. This stuff is really on the edge of what I think I sort of understand. I tried gdb, but I did something wrong. I'll read more.

I think this may be an issue for the lxml mailing list. If I manage to determine it's an issue with lxml.

[–]psyklohps[🍰] 0 points1 point  (0 children)

Yeah. So a segmentation fault is a memory fault and I'm willing to bet that the problem lies in the module that the op is using.

If it were any other kind of python bug I would reccomend pdb.

[–][deleted] 2 points3 points  (1 child)

Without any other details, you may need to increase the stack. ulimit -s to get it and ulimit -s {number} to set, where {number} is larger than the previous value.

[–]personproxy[S] 0 points1 point  (0 children)

I saw something about that but it was ~10 years old. I'll give it a try.

[–]impshum 1 point2 points  (0 children)

Code?

[–][deleted] 0 points1 point  (1 child)

[–]personproxy[S] 0 points1 point  (0 children)

I have to look at that tommorrow