I have have a mod_perl program that implements its own handler function (i.e. it's not using Apache::Registry).
I have a parser module written using Parse::RecDescent.
I have been successfully using the parser module in another similar mod_perl program for months with no issue.
Simply "use"ing the parser module in the my new mod_perl program (i.e. no references to functions in the module) causes the Apache server to spawn child processes until it hits it's max limit. Commenting out the "use" statement solves the problem (but leaves me without the use of the parser, obviously).
I suspect that the inclusion of the library is doing something that causes the Apache lifecycle to hang before it ends. I believe this is happening after the logging phase since the response is sent and the log is updated.
Anyone have any clues for me? I'm at a loss.
--phil--
I don't have an answer for you (personally, I use fastcgi...) but I can suggest an approach: attach strace, ltrace, gdb, etc. to the apache child process and see where its hanging. You may need to rebuild apache, mod_perl, and even perl with debug symbols to get reasonable output from gdb.
So, I solved the problem, but don't understand why it worked. That leaves me slightly frustrated, but I'm grateful that the problem's gone.
Before I took derobert's suggestion and traced the process, I decided to move the library load to the mod_perl startup file and voila, problem solved.
Interesting that it took me a day of work to get to the point where I understood the problem enough to ask the question on SO and then once I got to that point, a simple thing solved it.
Related
I've written a simple script that has multiple custom functions stored as modules. I have done it this way because I was always been told that if your function can be reused by other things then it should be a module and not a .\ source include. I'm starting to think that mantra isn't right in my current scenario. I am trying to convert the script to an single .exe so that I can install it as a windows service.
Probably should acknowledge that I understand why you wouldn't want to include system modules like Active Directory or IIS management for the obvious issue that could lead to but I'm only trying to include custom functions in a single disputable non editable way.
I have used PowerGUI in the past but can't find any valid exe's for that since DELL have removed it and from memory, I don't think I've ever used it with a module.
I've tried PS2EXE-GUI and PS2EXE. Both of these make the exe and everything works fine while the modules exist. However, as soon as I put the exe on a server that hasn't got the Modules deployed to it, it fails to run. I thought the compile followed all the dependencies and included them as part of the build into the single exe? That appears to not be the case.
I've also tried the PowerShell Studio 2018 by Sapien, but based on their forums you can't include modules into the complied exe. Which again feels wrong if they are actually just custom functions, but it's the way they've written it.
I see https://poshtools.com/docs/posh-pro-tools/merge-script/ would possibly do what I need but that's chargeable and it looks like it actually merges all the content back into a single file. Given the time pressure I'm starting to think I'll have to pay if there are really no other better options. I just don't have time to join everything together manually and I can't help thinking there is a better way I'm missing!
Can anybody please suggest other options?
Could I also get clarification around my original mantra (functions go in modules...)?
"No, never!" or "Yes, always!" or "It's just wrong in this scenario."
I am running the Sulley fuzzing tool, which uses pydbg to debug the target process. The pydbg threads are spawned in the process_monitor.py module of the Sulley environment. My problem is that when a test case (malformed packet) causes the process to crash, the debugger thread continues to run, and the following test case triggers an access violation.,This is then sent to the session module saying the wrong packet, the second test case caused the access violation.
I am trying to print the log information from pydbg to debug exactly what is happeneing, but nothing I do seems to be working. Obviously since this a thread it has no console to print to, so I've tried many different methods of writing to a file.
Even a very straight forward
logFile = open('C:\sulley_build\sulley\logFile.txt', 'w')
logFile.write("test")
won't create a file at that location. I know the pydbg thread is spawned, yet even putting that code in the _init__ function does nothing.
Help?
It's been a while since I've worked with the process monitor, but here's my advice:
Sulley had several procmon bugs when I used it. I submitted two patches here:
https://github.com/OpenRCE/sulley/pull/94
https://github.com/OpenRCE/sulley/pull/83
These bug fixes may be related to your issue (hard to tell with Sulley's architecture). I would give them a try. The fixes are already applied on my fork, or you can manually apply them in your own fork.
It sounds like the procmon is not reporting the crash properly. I distinctly remember this issue, but can't recall if the fixes mentioned above resolve it. If you do try to get it working, the key method is ProcessMonitorPedrpcServer.post_send.
If you want to report more crash details, try writing them into self.last_synopsis. See ProcessMonitorPedrpcServer.get_crash_synopsis.
Happy fuzzing!
I am using Eclipse Kepler Service Release 2 , EPIC 0.5.46 and Strawberry Perl 5 version 18 for perl programming. For debugging I am using Eclipse debugger and PadWalker .
I have an interactive perl program that writes to files based on answers provided by the users to multiple prompts. While debugging , every time i change a single line of code I have to rerun the whole program again and provide inputs to every prompt , which is really time consuming.
Is there a way to make changes to the code in a sub routine , in the middle of debugging session such that the instruction pointer resets itself to the first line of that sub routine. This way i do not have to restart the session to recompile the new code.
Appreciate your inputs and suggestions. Thank You!!!
What you want to do can be done, and I've done it many times in Perl myself. For example, see this.
However although what you describe may work (and is a bit dangerous), the way it is generally done a bit different and safer.
First one has to assume a regular kind of command structure like a command processor, or say a web server.
In a command processor or web server, you read a command (or get a web request), perform an action, then read another command, perform another action and so on. From your description, it sounds like you have such a structure.
In my case, I have each debugger command stored as in Perl file. This is helpful not only for facilitating this task, but also for understanding, testing and changing the code.
Given this kind of program structure, instead of trying to change the program counter, you complete the command and at the level where you are about to read a new command, you make the change and then reload the file which changes the code.
The specific Perl construct to do this is called do. Don't use require or use which will load in a Perl file only if that file or module hasn't been previously loaded. In your situation, you want to reload even if it has been loaded before.
So now how do you get to be able to issue a do command? As you suggest, you could do it through a debugger. Assuming you have this overall program stucture as described above, you put the breakpoint somewhere a common point in the caller which loops over things to process, rather than try to change things in indvidual commands.
And you don't even need a debugger to do this! Many web frameworks like Ruby on Rails, have a "development" mode where they save timestamps on files that implement functionality. If the file has changed they issue the "do" command before running the request.
I have a perl script, if i run it normally, it doesn't work right.
But if i run it with the debugger and set a breakpoint at a very specific line, then the script operates correctly.
What side effects can the, breakpoints of the ptkdb module, have?
Loading of any perl debugger has quite significant impact on all environment -- for an idea look into perldebguts. While the debuggers try hardly to minimize its effects, there are additional packages loaded, some special variable has different contents, timing of runtime changes, etc. Without more detail it is hard to say what difference is affecting you.
I would recommend to debug using logger (I found easy mode of Log::Log4perl very handy for this). Also many useful hints on debugging art is in perldebtut.
I never really came in touch with perl before, so I really hope, this is a real newbie question and I can solve the problem pretty quick...
We've one perl based web application installed on a windows 2003 server environment. The installed version contains a bug and I know where to apply the patch. Basically: I have carefully changed two lines in one of the web apps pm files.
To my surprise, the file change is ignored and I still get the same error messages with references to the old version of the file - clearly identifiable by the line numbers.
I've cleared the browser caches, restarted the web application (including apache) - no luck.
Now I think/hope that this is some kind of perl feature, but I even don't know enough of that language to ask google the right questions. One tutorial said, that perl is an interpreted language and that changes to source files are effective immediately. This isn't true for my site...
Are there some more caches/files I have to touch or delete in order to make my changes effective?
Are you sure your Perl is actually using the latest version of said pm file? There is no other version somewhere else included which is getting used?
Take a look at #INC
Step through your programming using a debugger
Sprinkle warnings around the code and see if it gets called.
Problem solved and the solution was outside perl - thanks for your patience.
The web application contained some javascript / css caching. After
deleting the caches (js-chache, css-cache)
clearing the browser cache
restarting Internet Explorer (!)
it started working again. Don't ask me why...