Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

program occasionally sticking - place of stick inconsistent

Status
Not open for further replies.

Kathy1

Programmer
Dec 21, 2000
39
0
0
US
Hi.

Sometimes the Perl programs in my system just 'stick' (aka stop processing) at inconsistent places in the code. By stop processing, I mean they get to a line of code and go no further...no error messages, no nothing...just the poor browser spinning into eternity until it times out. These sticky places are not in logical coding loops...just straight code. The programs in question call subroutines, and interface with an IBM DB2 database and use regular HTML (this is on an NT server). The server is a Dell w/ 256 ram and 800mhz speed.

Normally 'sticking' programs indicate a logical program loop (a 'while', for example) that never exits, which is generally pretty easy to spot and fix. But these 'stick'y situations are inconsistent in that they might happen to occur in program X 5 times, then don't occur in the system at all, then occur in program Y once, then in program Z 20 times (enough to track down the line of code), then appear in subroutine A 12 times, then disappear. Only to come back again. I've traced them down to the line of code that is sticking, using:

print "you are here1";
exit(0);

coding in the program. I move this exit routine through the program, starting at the top and skipping a few lines each time, changing the number at the end, until I find where it no longer prints and the system sticks. Then I backtrack the line of code until it does print...this gives me the 'sticky' line. Then, a few tests later, the line of code causing the problem isn't causing the problem. Either some previous line of code is 'sticking', some line in a subroutine is sticking, or the program just starts working fine.

When doing these track-down tests, I use the same input for each test, just hit stop on the browser (which doesn't stop the browser, by the way, it keeps spinning) and then click on the back button. So the data coming in from the screen is the same each time.

An example of a line of code I've gotten 'stuck' on recently is this:

$deleteIt = "N";

-or-

%variableArray = (%variableArray, "One_More", "Y");

These are normal lines of code that shouldn't be sticking.

I am thinking that perhaps there are some Perl parameters set on install, like the amount of processing space a given program can use, that might be getting used up and causing these weird situations.

Any insight into possiblities on this would really be appreciated. I've been doing research and trying various things for several days to fix whatever the problem is, all to no avail.

Thank you.

Kathy
 
Sorry - my mistake. The server has dual 733mhz processors...just fyi.

Kathy
 
Weird......

What version of Perl are you using? Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.
 
Well, that's a good, recent, version.

Have you looked at your installation of NT? Is it all patched up, is the machine running other programs that might be taking a lot of processing time or interfering woth Perl? Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.
 
Thanks for that idea Mike. I'll pass it on to the tech services dudes to see if they can find anything. But the server is new, the installation of NT is new, etc...

I think that the programs don't have enough processing power, somehow. I used to work on mainframe, and there we could increase the space/umph a program had at its disposal by using REGION=xxxK in the job control. Do you happen to know if there is a similar paramter somewhere on servers or within application programs that can be set to give a program more processing space?

Thanks!

Kathy
 
"a similar paramter somewhere on servers or within application programs that can be set to give a program more processing space?"

<wry smile> I wish... </wry smile>

Sorry I couldn't be of more help Kathy Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.
 
Guess that probably was one of those 'dumb' questions...but I had to ask it. PC's and mainframes are alike in a lot of ways, but different in lots of ways, too.

I wrote a new, smaller program that gets stuck as well. These programs also access a DB2 database. Seems that if I commented out a cgi 'die' statement on the database DBI connect, it wouldn't get stuck...or I could leave the 'die' there and comment out the 'use CGI qw:)standard);' statement, and it wouldn't get stuck. But then, it doesn't always get stuck even if both those are un-commented...just often enough to be a pain in the you know what. It might work fine 50 times, then start sticking every darn time. Or, it might stick the first time and just keep on sticking (like the Energizer Bunny). Its very irritating and I can't put the system in 'live' until this problem is resolved. If anyone is interested, I can post the program. Also, if I figure out what is causing it, I'll be sure to post the resolution.

Thanks for your help. :)

Kathy
 
You have OBVOIUSLY pissed of the digital gods. Sacrificing small semiconductors on a stone altar might help!

Is your perl executable built on the machine you are running or are you running a pre-built executable? It may pay to rebuild Perl on your servers (CPU dependencies, specific releases of libraries etc.)
Glen Colbert
gcolbert@RAG_American.com

 
Hi Glen.

I have forwarded your question regarding the building of Perl on the server to my tech services guru dude. I'll have to get back to you on that - hopefully he gets back to me soon. I didn't install it myself, so am unable to answer that particular question.

As far as the sacrifice, I am beginning to think that small semiconductors just won't cut the mustard. Have to go in for something a little more substantial...like maybe an entire drive or the whole darn server! :)

Do you know, or anyone else who happens to be following this thread, if there is such an animal as a 'storage violation' using Perl? This would be similar to having a run-away array or something that starts over-writing parts of programs, files, whole programs, and other such stuff when its obviously not supposed to. It does this because it grew much bigger than was expected. Is storage violation the correct terminology?

Thanks!

Kathy
 
Perl does it own memory management dynamically. Unless your program is gobbling all the RAM and all the swap space (virtual memory on a Win OS), it should not be problem. That seems a little unlikely since you say the code frequently run through to completion. If it were a logic problem that ran away building an array or hash or other, then I don't see how it could hang like you describe.

Here's a thought from left field...., is it possible that you are using files or resources from an NFS mounted file system? If so, I have seen erratic behavior like this when the host that owned the file system came under a heavy load. OR, when a network problem prevented access to that file system. I once saw a PC network card cause intermittent snow storms that would hang us from time to time. I hope that is not your problem. We tried to figure that one out and could not for a long time until the problem got bad enough for us to identify the culprit. The PC showed no symptoms, but, it was briefly and intermittently causing a flood over the network which interrupted everyone else.

Good Luck.


keep the rudder amid ship and beware the odd typo
 
Hi all.

Thanks for all of your suggestions on the sticky problem.

The test system still sticks. I put in some code to take care of i/o buffering, added exit(0) to the end of all the programs, $STH->finish; to the DB2 reads/writes/updates/deletes, and lots of other little tweaking to the programs.

Interesting note - we moved the system over to the production server (it is not available for commercial use yet, but we put it there for testing purposes) and we don't seem to be having the 'sticky' problems. At least not so far.

I think that Perl (or something) isn't releasing files like I want it to, and it is sticking the next time Perl tries to use a file, in particular situations. I've seen this with my error log files, where even though the programs aren't being used, if I try to delete them, I get sharing violations; and I've seen it happen with the DB2 files if I happen to be browsing one using the database software at the same time that one of the Perl programs is trying to access that table. If not Perl, then perhaps the webserver software is holding them.

This type of activity won't be happening very often on our production server. We won't be browsing database files, and to look at the error logs, I have to run a special job to copy them over to my C: drive for viewing. So, if file sharing/releasing (or not, in this case) is what is causing the stickiness, then it should happen very seldom, if ever, on our production server.

But, does anyone know a command (other than unlink) to release a file? I am unlinking the error log files at the end of each Perl program, right before the exit(0); command.(unlink doesn't delete them, for some reason, but I thought it should free them up for the next user).

Thanks! :)

Kathy
 
you could just do [tt]system &quot;rm file.log&quot;;[/tt], or whatever the window's equivelent is. &quot;If you think you're too small to make a difference, try spending a night in a closed tent with a mosquito.&quot;
 
Hi everyone.

Just wanted to clean up this thread - finally. We had our tech services people un-install Perl and re-install it. We have had no sticky problems since this was done - about 6 weeks ago. So, the problem has been resolved, and obviously it was either something in the original installation process or we somehow whacked a file that it was needing.

Again, thank you all for all of your help and suggestions.

Kathy :)
 
:)

Finally....!

Glad you're sorted Kathy. Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top