[mp2] Segmentation faults with threaded worker-mpm

Hi all, I have a problem with segmentation faults which I've been unsuccessful at solving so far. These only occure when running the handler+filter in a threaded worker-mpm setup, a preforked environment does not have any problems. First, the environment. I am running on Debian Etch, with Ap

Re: [mp2] Segmentation faults with threaded worker-mpm

Perrin Harkins wrote: Are you sure about that? On Linux, prefork is likely to perform better. Threads will use up a lot more memory, and be slow to spawn. I think you should try a little benchmarking before you put a lot more time into using threads. You are correct in that performance (cpu u

Re: [mp2] Segmentation faults with threaded worker-mpm

Perrin Harkins wrote: No, it's just the opposite. Using prefork won't save CPU, but it will save memory, meaning you can run more perl interpreters. I'm sorry, but I have to disagree here - especially with the configuration I need. Let's take the server with 1 GB of memory as an example. W

Re: [mp2] Segmentation faults with threaded worker-mpm

Torsten Foertsch wrote: These figures match my observations. It also means that you are not using big content generators in the response phase like Catalyst. Correct. Response content is generated by backend servers, which is then delivered to clients either from the local cache, or via mod_pr

Re: [mp2] Segmentation faults with threaded worker-mpm

Perrin Harkins wrote: If what you're saying is that you can't separate out the mod_perl bits with a proxy because they do things like authentication, you might be That's unfortunately exactly the problem. It's not authentication, but the mod_perl bits are still required before proxying can be

Re: [mp2] Segmentation faults with threaded worker-mpm

Perrin Harkins wrote: > Honestly, the person who has done the most work on debugging thread > crashes is Torsten. His advice on how to debug it will be better than > mine. It does seem like people usually solve them by using backtrace > analysis though. Getting back to this, I've now had time t

Re: [mp2] Segmentation faults with threaded worker-mpm

Try "PerlInterpScope request" and see if the coredumps disappear. Further check if it's always this place. PerlInterpScope request did not help. I just tested, and still got a segfault. As far as I have seen, all the segfaults seem to be mgv related, but not at the exact same spot. One odd

Re: Reading post-data

Reif Peter wrote: Unfortunately you cannot tell $r->read to read just all of the data, you must provide a length. How do I solve this problems. $r->read will return 0 when no more data is available. I have been using the following simple code with success: my $postdata = ""; while ($r->read

Re: [mp2] Segmentation faults with threaded worker-mpm

Jani M. wrote: As far as I have seen, all the segfaults seem to be mgv related, but not at the exact same spot. I've still been trying to identify the root cause of the crashes, but unfortunately haven't had success yet. Some of the things I've tried so far: - Different

Re: [mp2] Segmentation faults with threaded worker-mpm

Jani M. wrote: I've still been trying to identify the root cause of the crashes, but unfortunately haven't had success yet. Looks like success at last. I managed to tune my test environment server load from <30 requests/s to 500+ requests/s. This in turn started producing seg

Re: [mp2] Segmentation faults with threaded worker-mpm

Torsten Foertsch wrote: Try $r->push_handlers(PerlFixupHandler => 'My::fixup_handler'). Doesn't make any difference unfortunately. Strange though, when I use the hard reference \&fixup_handler, the lookup-errors (which are sometimes corrupted) in the log still display as My::fixup_handler.