mod_perl debugging application debugging in shared environments

[Dmitriy Ryajov <dr...@gmail.com>]

I'm running in a shared development environment. I can't run httpd in 
non detached mode on that machine because the server is used by other 
devs at the same time, and there is absolutely no way I can get my own 
sandbox set up. Is there a way that I can run an interactive debug 
session without running http -x? I'd also like to know what are the 
reasons of such limitations (if there are any), and if there are any 
viable workarounds.

I'm willing to invest time into adding the required functionality into 
mod_perl/Apache::DB if necessary, so any pointers into why and how, are 
greatly appreciated.

Thanks,
Dmitriy Ryajov.

Re: mod_perl debugging application debugging in shared environments

[Dmitriy Ryajov <dr...@gmail.com>]

Still would be useful to get something more solid going - but I agree, 
for the time being, I'll might just as well go with what your suggesting.

I also looked at edebug, looks pretty cool and might be something I can 
use to setup a viable debugging environment for my situation - even 
better it seems to support remote debugging out of the box (more or 
less), and adding support to IDEs doesn't seem that difficult. Will 
definitely spend some time looking at it.

Thanks for your help,
Dmitriy.

On 11/18/2011 4:36 PM, Perrin Harkins wrote:
> On Fri, Nov 18, 2011 at 3:58 PM, Dmitriy Ryajov<dr...@gmail.com>  wrote:
>> The reasons are mostly legal, the client simply won't allow me to set it up
>> outside the dedicated server. There are also technical reasons, the system
>> is massive and too tight up to the rest of their internal infrastructure.
>> I'm working with an ssh session with the code pulled to my home and mapped
>> to a virtual host in apache 2.2, the rest of the devs are working in the
>> same manner under that same Apache server.
> Ok, what I would do in this situation is run my own apache on a high
> port on that same server.  I'd copy the conf file, change the port,
> and run httpd with my custom conf.  It's still on the same server,
> still has access to everything, but can be run under the debugger.
>
>> To repeat my question, are there any specific reasons, besides output
>> redirection that prevent the debugger running in a
>> multiprocess/multi-threaded host?
> None that I know of, but this is outside of my expertise.  I remember
> seeing some stuff about debugging forked processes on PerlMonks,org.
> You might want to have a look there.
>
> - Perrin

Re: mod_perl debugging application debugging in shared environments

[Perrin Harkins <pe...@elem.com>]

On Fri, Nov 18, 2011 at 3:58 PM, Dmitriy Ryajov <dr...@gmail.com> wrote:
> The reasons are mostly legal, the client simply won't allow me to set it up
> outside the dedicated server. There are also technical reasons, the system
> is massive and too tight up to the rest of their internal infrastructure.
> I'm working with an ssh session with the code pulled to my home and mapped
> to a virtual host in apache 2.2, the rest of the devs are working in the
> same manner under that same Apache server.

Ok, what I would do in this situation is run my own apache on a high
port on that same server.  I'd copy the conf file, change the port,
and run httpd with my custom conf.  It's still on the same server,
still has access to everything, but can be run under the debugger.

> To repeat my question, are there any specific reasons, besides output
> redirection that prevent the debugger running in a
> multiprocess/multi-threaded host?

None that I know of, but this is outside of my expertise.  I remember
seeing some stuff about debugging forked processes on PerlMonks,org.
You might want to have a look there.

- Perrin

Re: mod_perl debugging application debugging in shared environments

[Dmitriy Ryajov <dr...@gmail.com>]

Thanks Perrin.

The reasons are mostly legal, the client simply won't allow me to set it 
up outside the dedicated server. There are also technical reasons, the 
system is massive and too tight up to the rest of their internal 
infrastructure. I'm working with an ssh session with the code pulled to 
my home and mapped to a virtual host in apache 2.2, the rest of the devs 
are working in the same manner under that same Apache server. So as you 
can probably imagine its a PITA. Interactive debugging would speed up 
development tremendously.

With my brief preliminary research, I found xdebug for PHP, its build 
upon DBGp and it does not require to run apache in detached mode, so in 
theory at least, mod_perl can support the same. I'm not suggesting to 
buildin support for DBGp (unless Perl's debugger already has it, which I 
doubt), but having the ability to debug without the single apache 
process limitation would be of great help - with out of the box remote 
debugging being a plus.

So, as stated bellow, I'm willing to invest time into getting this 
working. To repeat my question, are there any specific reasons, besides 
output redirection that prevent the debugger running in a 
multiprocess/multi-threaded host? I would greatly appreciate any 
insights pointers in where to look for answers in the mod_perl sources 
and documentation.

Eagerly awaiting for your answers. Please don't let this sleep through, 
I'm quite serious about this ;-).

Thanks,
Dmitriy.

P.S
Print and Data::Dumper debugging will drive me crazy pretty soon - we 
need this ASAP.

On 11/18/2011 12:42 PM, Perrin Harkins wrote:
> On Fri, Nov 18, 2011 at 12:48 PM, Dmitriy Ryajov<dr...@gmail.com>  wrote:
>> I'm running in a shared development environment. I can't run httpd in non
>> detached mode on that machine because the server is used by other devs at
>> the same time, and there is absolutely no way I can get my own sandbox set
>> up.
> I suspect that finding a way to run your own is going to be easier
> than inventing a new way to debug perl.  Can you tell us anything
> about the barriers to running your own server?  We might be able to
> suggest something.
>
>> Is there a way that I can run an interactive debug session without
>> running http -x?
> You need a console attached, so I don't think so.  You could look at
> what others have done with trying to debug forked programs, but
> daemons like apache try pretty hard to detach from everything.
>
>> I'm willing to invest time into adding the required functionality into
>> mod_perl/Apache::DB if necessary, so any pointers into why and how, are
>> greatly appreciated.
> If I were going to try to do this, I'd probably start with
> http://search.cpan.org/dist/Devel-ebug/ and see if it can be hacked to
> work as a remote debugger for mod_perl.
>
> - Perrin

Re: mod_perl debugging application debugging in shared environments

[Perrin Harkins <pe...@elem.com>]

On Fri, Nov 18, 2011 at 12:48 PM, Dmitriy Ryajov <dr...@gmail.com> wrote:
> I'm running in a shared development environment. I can't run httpd in non
> detached mode on that machine because the server is used by other devs at
> the same time, and there is absolutely no way I can get my own sandbox set
> up.

I suspect that finding a way to run your own is going to be easier
than inventing a new way to debug perl.  Can you tell us anything
about the barriers to running your own server?  We might be able to
suggest something.

> Is there a way that I can run an interactive debug session without
> running http -x?

You need a console attached, so I don't think so.  You could look at
what others have done with trying to debug forked programs, but
daemons like apache try pretty hard to detach from everything.

> I'm willing to invest time into adding the required functionality into
> mod_perl/Apache::DB if necessary, so any pointers into why and how, are
> greatly appreciated.

If I were going to try to do this, I'd probably start with
http://search.cpan.org/dist/Devel-ebug/ and see if it can be hacked to
work as a remote debugger for mod_perl.

- Perrin