Anyone ever experienced something like that? I'm installing OpenCMS 8.5.0. for evaluation, running on Tomcat 7x, and during the 8th step of setup (Installing Modules), the process freezes - I've got stuck for a long time in a same line (I left it the way it was, and hung out for coffee for 30-40 minutes), without any update.
What have you done?
Thanks,
*** Edited from this line ***
I've tried to refresh the page (After coming back from my coffee break), and it only cleared the logs. So I stopped the server and re-started it again. The process started from beginning (I had to drop the database and create it again), the processes freezes again, I waited some time, a tried to refresh the page sometimes, again I faced logs inside the 'textarea' the being cleared, after some tries, the process was finally finished.
Anyone have faced the same experience?
Things to check:
How much max. heap is assigned to the Tomcat? 64MB as the default standard? Eventually tried to increase that parameter?
Can ou check the log (WEB-INF/logs/opencms.log) or the catalina.out - do you see any errors in there?
I have OpenCms 8.5 running on Tomcat7 without any problems.
Which OS are you on? Windows, Linux, Mac?
Related
I have a new Win10 laptop. I've installed lots of software, including a 25-year-old Codewright editor that I've customized up the wazoo, and that I've been installing on all my machines for, well, 25 years. After working for a few days, it suddenly stopped, and reinstalling it didn't fix it. On startup, it puts up a small splash window, and normally opens the main window a half a second later (that took more than 5 seconds 25 years ago). It's not using any CPU, and there's nothing I can do but kill the process.
In the past, I've occasionally got my system into a state where Codewright would hang on loading, due to some other program that hadn't terminated correctly, and it was unfrozen by killing off that other process. So that's reason to believe that Codewright is waiting at some global lock which some other malfunctioning software is holding. So I have two questions:
Does this ring a bell? Is there some known failure mode where a program putting up a splash window then switching to another window can be prevented by something else going on the system?
Is there a way to diagnose this, perhaps by finding out what system call it's hanging inside? I tried dtrace.exe, started Codewright, and then stopped tracing, and it produced a 3GB XML file, which is quite a haystack. There's a way to filter it by PID, but since this is a startup problem, I have no idea what the PID will be. Is there a better tool for doing this, or some more appropriate dtrace feature that I missed?
The comment about using the Task Manager to create a dump file actually led me to notice that there is an Analyze Wait Chain function there that I had never seen before, since I haven't used Task Manager much since I switched from Win7. This gave me exactly the answer I wanted. My editor was waiting for something that was being held by some NVIDIA GeForce Experience module. Since I don't use that, I uninstalled it, and I'm back up and running. Thanks for the tip.
After several months of successful and unadulterated continuous integration, my Hudson instance, running on Mac OSX 10.7.4 Lion, decides it wants to enter shutdown mode after every 20-30 minutes of inactivity.
For those of you familiar with shutdown mode, the instance of course doesn't shutdown, but has the undesirable effect (in this case) of stopping new jobs from starting.
I know I haven't changed any settings, so it makes me think the problem was slowly growing and keeps triggering shutdown mode.
I know there is plenty of storage space on the machine with 400+ GB to go so I'm wondering what else would trigger shutdown mode without actually using the Hudson web portal to manually do it.
As mentioned before, the problem also seems to be tied to inactivity. I tried creating a quick fix, which is a build job that does nothing every 5 minutes. It appeared to work at first, but after long periods of inactivity I will find it back in shutdown mode.
Any ideas what might be going on?
Solution: disable the thinBackup plugin
...
I figured this out by taking a look at the Hudson logs at http://localhost:8080/log/all
thinBackup was running every time the Hudson instance went into shutdown mode.
The fact that shutdown mode was occurring at periods of inactivity is also consistent with the behavior of thinBackup.
I then disabled the plug-in and Hudson no longer enters shutdown mode. What's odd is that thinBackup had been installed for some time before this problem starting occurring. I am seeking out a solution from thinBackup to re-enable the plugin without the negative effects and will update here if I get an answer.
According to this link, the thinBackup plugin puts Hudson into shutdown mode on purpose to do the backup activity. It is supposed to automatically come out of shutdown mode once it is done.
I saw this with some jobs that seemed to stall and never finish overnight, so Hudson never came out of shutdown mode because thinBackup must have been waiting on the jobs to finish.
I'm on windows 7 x64. Using C++ in Visual Studio 2008 and 2010.
When I run any own application with VS after, aprox, 15 seconds the application is forced to exit. No messages, no Exceptions, no nothing. It doesn't matter how simple it is the application.
After a couple of weeks reviewing and commenting my code, I tried by reinstalling my S.O. and programs, thinking in some driver update or something similar. Whatever it was should solve my problem. That didn't solve the problem either.
You can see an example in
https://twitter.com/#!/nachovall/status/176996407780188160/photo/1/large
Note that it hasn't empty the buffer!! Just crazy.
I'm thinking in some whatchdog problem. I mean some, windows 7 issue which causes a given application to exit after some seconds.
The worst thing is that I have no idea about how to search this in Google. 'Silent crash'? It's not crashing, just exiting.
Well, if anyone knows what the problem is... you know.
By the way, I did a whole hardware analysis looking for some CPU or Memory problem. Nothing found.
Even more. I run the debug. I set a breakpoint in the first line of code. The application is doing nothing. Just waiting me to step over in the debugger. After 15 seconds, the application ends. Cool ha?
Ok, all night awake but finally found.
It was the antivirus program. Avast version 7.0.1407. When I disable it, everything get sense again.
It's been 2 weeks. 2 large and exhausting weeks. Anyone who's using this antivirus, please be aware.
I have to run this program millions of times. It's not the most stable beast, and it crashes around 5% of the time. When this happens, I don't want a popup, or WerFault to take 30 sec to take a dump, or anything - I just want it to silently and immediately disappear, and I'll figure out it crashed from the process exit code.
I already have Windows Error Reporting Service disabled, and my AEDebug key deleted. However, werfault is still trying to take a dump on crash. Help?
That can be annoying... especially if you're doing a lot of code-debug-compile-deploy-test iterations.
It looks like there are a couple of registry entries here that help control the behavior:
http://msdn.microsoft.com/en-us/library/bb513638(VS.85).aspx
Here's some information on how to exclude your particular application from error reporting, without completely disabling error reporting:
http://msdn.microsoft.com/en-us/library/bb513617(v=VS.85).aspx
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.