I'm trying to start an Erlang app that is failing. All I see in the shell is:
=INFO REPORT==== 7-Jan-2010::17:37:42 ===
application: ui
exited: {shutdown,{ui_app,start,[normal,[]]}}
type: temporary
How can I get Erlang to give me more information as to why the application is not starting? There currently is no other output in the shell.
You could try launching the shell with more logging support:
erl -boot start_sasl
this might get give a bit more details.
There is a patch (tp/supervisor-pass-on-errors) that was included in release R16B. This patch makes exit reasons appear in application stop log messages, which thus become much more useful than the {shutdown,{ui_app,start,[normal,[]]}}-style messages we've had until now.
This is the entry in the README:
OTP-10490 == stdlib ==
If a child process fails in its start function, then the
error reason was earlier only reported as an error report
from the error_handler, and supervisor:start_link would only
return {error,shutdown}. This has been changed so the
supervisor will now return {error,{shutdown,Reason}}, where
Reason identifies the failing child and its error reason.
(Thanks to Tomas Pihl)
It is a pain, but the way I do it is the old fashioned way, by writing io:format's into the start function of the application (ie the code of the module with the behaviour of application) and working out which line fails :(
Sometimes brute force and ignorance is your only man...
Related
I'm out of my wits. I'm trying to set up remote debugging of lua code in dockerized openresty. I use PHPStorm with EmmyLua extension, and the mobdebug library on the Lua end. I have been reading and hearing reports of this working for people, but for me stopping on a breakpoint (or immediately after mobdebug.start()) works about 15% of the time (evidence that I am not completely misconfiguring the thing), including exactly 0% of those places in my code that I actually want to debug.
I will not be debugging this issue. I intend to work around it by using an exact setup that is known to work, so I need someone for whom it does work to tell me what their setup is:
OS version
openresty version
mobdebug version
any custom patches or hacks you might have applied to get the debugging working
luasocket version (probably relevant)
PHPStorm version
EmmyLua version
docker and docker-compose version, if applicable
whatever you may suspect to be relevant
I am willing to completely raze my development environment and rebuild it exactly to the working spec, just to have working Lua debugging.
EDIT: for those interested, here are my detailed symptoms:
I can't stop at actual breakpoints, ever (i.e. after I initially stop after mobdebug.start() and then "Resume program" and a line with a breakpoint is hit, but it doesn't stop there)
I can stop after mobdebug.start() in code executed from init_by_lua_block, i.e. once per server start / config reload
I can't stop after mobdebug.start() in any code executed during handling a request, i.e. ssl_certificate_by_lua_block, rewrite_by_lua_block etc. This is probably understandable because coroutines are involved
All my attempts at enabling coroutine debugging in request handling code either error out or have no effect:
mobdebug.coro() in init_worker_by_lua_block() errors out with "API disabled in current context" somewhere in mobdebug.lua
mobdebug.on() in the function I want to debug either has no effect, or errors out with "attempt to yield across C-call boundary"; I haven't discerned the pattern yet.
stopping on a breakpoint (or immediately after mobdebug.start()) works about 15% of the time
Stopping after mobdebug.start() should work under all circumstances, except when there is a connection already established to the same debugger controller, so the fact that it doesn't usually points to the system that tries to establish multiple debugging sessions to the same controller/IDE (or no connection can be established at all).
Similarly, there are several reasons why breakpoints may not be working, but if they work in a file as part of a specific setup, then I'd expect them to always work in that case. Some of the reasons why breakpoints may not be working are listed in the documentation: https://studio.zerobrane.com/doc-faq#why-breakpoints-are-not-triggered.
mobdebug provides a command line-based controller, so for troubleshooting purposes it may be easier to use that instead of a more complex setup.
I've been working through the Erlang tutorials in Seven Languages in Seven Weeks using Erlide for eclipse and for the most part all seemed to be ok until i got to the concurrency section.
In this section, the author walks through a simple example
loop() ->
receive
"casa" ->
io:format("house~n"),
loop();
"blanca" ->
io:format("white~n"),
loop();
_ -> io:format("no comprendo~n"),
loop()
end.
When running as suggested by the book i should be able to send messages with Pid ! "someStuff". However when running this, nothing is returned and the debugger requires i kill the process before any activity resumes.
Here's an example of the console. You'll see when i send the message, nothing is returned.
Eshell V5.10.4
(ErlangDay3#Jeff-PC)1> Pid = spawn(fun translate:loop/0).
<0.202.0>
(ErlangDay3#Jeff-PC)2> Pid ! "casa".
Pid ! "hello?".
WhatJustHappened.
This all seems to run perfectly through the command line directly with Eshell (without eclipse and erlide). Could i have missed some configuration somewhere? I'm now completely stumped. I realize that maybe SO is not the best place for a question like this, however i've completely exhausted my google-fu and it doesn't appear that erlide has any forum presence.
Thanks for any and all advice.
In case it helps anything i'm running windows 7 and eclipse (STS, 3.3.0), with Erlang 5.10.4 (R16B03-1)
Thanks for the report!
This was a bug that I was hunting unsuccessfully since a while back, but now I managed to find and fix it. Please try the latest nightly build from http://download.erlide.org/update/nightly
I feel like I'm missing something stupid obvious, but I've looked all over and can't find the answer to my question.
Suppose I have an application release that I've built with rebar and I start it a la
rel/my_app/bin/my_app start
I let it happily go about its business for a while, and then I want to attach a console to check on things, so I do
rel/my_app/bin/my_app attach
and get a shell. I muck around, and then when I'm done I want to quit the shell but leave the application running. If I do ^G q or q()., it brings down the entire application.
I've also played with starting the app with +Bi to stop it from allowing someone to accidentally close it, but then how does one even exit an attached shell at all?
I don't use rebar, I've never understood what problem it was meant to solve, but I assume when you "attach" you are doing the same thing as running to_erl. To exit in from this you type control-D (EOF).
CTRL-D should get you out and keep the app running.
Eshell V10.7 (abort with ^G)
$ Ctrl^G
$ q
here，you can quit the remote console
If it's an ordinary remote shell, hitting Ctrl-C twice ought to do the trick.
A very simple situation. I'm working on an application in Delphi 2007 which is often compiled as 'Release' but still runs under a debugger. And occasionally it will run under SilkTest too, for regression testing. While this is quite fun I want to do something special...
I want to detect if my application is running within a debugger/regression-tester and if that's the case, I want the application to know which tool is used! (Thus, when the application crashes, I could report this information in it's error report.)
Any suggestions, solutions?
You can check the parent process that started your application.
With CreateToolhelp32Snapshot/Process32First/Process32Next get the parent PID (PROCESSENTRY32.th32ParentProcessID or TProcessEntry32.th32ParentProcessID) for your application PID. Then get the filename for the parent PID to compare with the applications you want to check for, like SilkTest.
Check this article for code usage.
In addition to IsDebuggerPresent and CheckRemoteDebuggerPresent, you can also query PEB.BeingDebugged (PEB is Process Environment Block, to get PEB you must query TEB, which is the Thread Enviroment Block).
You're probably looking for the IsDebuggerPresent function.
To detect SilkTest, you could try to attach to a DLL which is used only by SilkTest in order to detect its presence. For example, if the Open Agent is attached to a process, Win32HookDll_x86.dll or Win32HookDll_amd64.dll will be present (the names can be easily found out with a tool like Process Explorer.
You can also do
if DebugHook <> 0 then ...
I have a windows service that is failing to start, giving an error "Error 1053: The service did not respond to the start or control request in a timely fashion".
Running the service in my debugger works fine, and if I double click on the the service .exe on the remote machine a console window pops up and continues to run without problem - I can even see log messages showing me that the program is processing everything the way it should be.
The service had been running fine previously, though this is my first time, personally, trying to deploy it with the most recent changes made to the program. I've evaluated those changes and cant figure out how they might cause this problem, particuarly since everything runs fine when not started as a service.
The StartRoutine() method of the service impelmentation is empty, so should be returning in a "timely fashion".
I've checked the event logs on the computer, and it doesn't give any additional information other than it didn't hear back from the service in the 30 second requisite time frame.
Since it works on my machine, and as a double-clicked executable, how would I go about figuring out why it fails as a service?
Oh, and it's .NET 2.0, so it shouldn't be affected by the 1.1 framework bug that exhibited this symptom (http://support.microsoft.com/kb/839174)
The box is a windows server 2003 R2 machine running SP2.
This is a misleading error. It's probably an unhandled exception.
Empty your OnStart() handler then try this in your constructor...
public MainService()
{
InitializeComponent();
try
{
// All your initialization code goes here.
// For instance, my exception was caused by the lack of registry permissions
;
}
catch (Exception ex)
{
EventLog.WriteEntry("Application", ex.ToString(), EventLogEntryType.Error);
}
}
Now check the EventLog on your system for your Application Error.
Could be a number of things and it might help to get a stack trace on the machine exhibiting the problem. There are a number of ways to do this but the point is that you have to see where this is failing in the code.
You can do this with remote debugging, but a simple thing might be to just log to the event logger, or file log if you have that. Literally, putting "WriteLine("At class::function()") throughout portions of the code to see if you've made it there.
This will at least get you looking in the right direction (which ultimately is the code).
Update:
See Microsoft's How to Debug Windows Services article for details in troubleshooting startup problems using WinDbg.
This related question details nice ways to debug services that are written in .NET.
I agree with Scott, the easiest way to find out what's happening is to put some traces in the start-up code (maybe it doesn't even come to your start-up code).
If this doesn't help, you can post your code here so others can take a look.
perhaps lacking some dependence, try this :
- deregister your service
- register again
If fail at register means that lack an module.
If the StartRoutine is empty, you are probably starting it somewhere else.
IIRC you need to fire off a worker thread, and then return from StartRoutine.
One of the problems which may lead to this error is if windows service which needs to be deployed consists of some error i.e it may be simple authorization error or anything as in my case I have referenced some folders and files for logging which were not existing, but when provided the right path of those file and folders it solved my problem.
I ran through every post on this particular subject and none of the responses solved the problem, so I'm adding this response in case this helps someone else. Admittedly this only applies to a new service, not this specific case.
I was writing a File listening service. As a console app, it worked perfectly. When I ran it as a service, I got the same error as above. What I didn't know (and many of the MSDN articles about services conveniently leave out) is that you need to have your class executed from within ServiceBase.Run( YourClassName());. Otherwise, your app executes and immediately terminates and because it terminated, you get the error above even if no error or exception occurred. Here is a link to an article about this. It actually discusses setting up your app for dual use - Console app and service: Create a combo command line / Windows service app
I had that issue and the source of my problem was config file. I edited it in notepad and notepad added one special character which cause service not to run properly because config file was ruined. I saw that special character in notepadd++ and after delete it, service started to run successfully as previous did.
In my case, the correct .NET framework was not installed on the server that I was installing the Windows service on.
One other reason is If you copy the DLL in 'debug' mode to installation folder this issue will come.What you need to do is Run the project in 'Release' mode copy the DLL or directly form Release folder rather than Debug folder,,and copy that DLL in to installation folder,it will work.You can see the reduction in size of DLL ,it will not contain any debug symbols and like that