I am using mobDebug. If run a lua script from command line everything works.
But when I run them from openresty the Idea doesn't stop. It only writes "Connected/ Disconnected"
Configs:
location / {
access_by_lua_block {
local client = require("client")
}
client.lua:
local mobdebug = require("mobdebug");
mobdebug.start()
local lfs = require("lfs")
print("Folder: "..lfs.currentdir())
modebug debug_hook is not invoked for needed lines, set_breakpoints don't invoked.
Idea Debug Logs, but nothing occures:
Idea catch debug from terminal client.lua; But it miss it from running nginx.
THIS IS NOT AN ANSWER. It's just that I am experiencing basically the same problem, and comment space is too small to fit all the relevant observations I would like to share:
I was actually able to stop immediately after mobdebug.start() in code running in nginx, and to step-debug - but only in code called directly from init_by_lua_block. This code of course executes once during the server startup or config reload.
I was never able to stop in worker code (e.g. rewrite_by_lua_*). mobdebug.coro() didn't help, and mobdebug.on() threw about "attempt to yield across C-call boundary"
I was only ever able to stop one time, on next statement after mobdebug.start(); once I hit |> (Resume program), it won't stop on any further breakpoints.
Using mobdebug.loop() is not a correct way to do this, as it's used for live coding, which is not going to work as expected with this setup. mobdebug.start() should be used instead.
Please see an example of how this debugging can be setup with ZeroBrane Studio here: http://notebook.kulchenko.com/zerobrane/debugging-openresty-nginx-lua-scripts-with-zerobrane-studio. All the details to how paths to mobdebug and required modules are configured should still be applicable to your environment.
Related
Prerequisites: Running on Ubuntu. Using Apache. Yii version is printing 1.1.2.
My question:
I'm helping a friend out with a web app where his application developer abruptly quit. The problem is, I'm somewhat green with PHP and COMPLETELY green with Yii. I'm having a difficult time setting up a test server using the existing code. What's happening is the index.php code calls a CWebApplication-derived class, but the run() method never returns, and all I get is a blank page (this obviously doesn't happen in production). I'm trying to understand how to identify what's happening, and where the execution is just dying.
First, let me say that I ran http:///yii/requirements/index.php, and the requirements checker claimed I had the minimum requirements to run.
Second, my index.php looks like this:
ini_set('display_errors',1);
// change the following paths if necessary
$yii=dirname(__FILE__).'/yii/framework/yii.php';
$config=dirname(__FILE__).'/protected/config/main.php';
$gapi = dirname(__FILE__) . '/protected/vendors/Google/autoload.php';
// remove the following lines when in production mode
defined('YII_DEBUG') or define('YII_DEBUG',true);
// specify how many levels of call stack should be shown in each log message
defined('YII_TRACE_LEVEL') or define('YII_TRACE_LEVEL',3);
require_once($gapi);
require_once($yii);
/*
* Manage URL Uppercase or lowercase
*/
$manage_url_path = dirname(__FILE__) . '/protected/components/ManageUrl.php';
require_once( $manage_url_path );
$create_web_application = new ManageUrl($config);
$create_web_application->run();
When $create_web_application->run() executes, it never returns (printing after it prints nothing), and I get just a blank page.
This class (ManageUrl) overrides createController, but so far it feels like execution never makes it to this function. Placing any print() statements in there shows nothing. $Yii::log() also shows nothing. There's nothing in the application.log under /runtime. Apache's error logs are showing nothing too. It's as if code execution is just going into a black hole.
One final thing to note: I've got mod_rewrite enabled on the server. I followed this outdated howto on DigitalOcean to get things started (https://www.digitalocean.com/community/tutorials/how-to-install-and-setup-yii-php-framework-on-ubuntu-12-04).
Can you advise me on how to figure out what's going on with this application and why I just get a blank page? I need to figure out where the code execution is going and subsequently dying.
I try to execute the community script "Extender/HTTP Message Logger.js". I first double click on the script to make it open in the scripting console. However, in the scripting console, the "Execute" button is disabled and I see no other way how to make it run.
What am I missing?
I think you're missing the message beneath the script which says:
Extender scripts add new functionality, including graphical elements
and new API end points.
Enabling a script installs it and disabling a script uninstalls it.
So you just need to enable the script (by right clicking it and selecting 'Enable') and then it will start working.
The actual issue was that I didn't read the script's code carefully: be default the script only logs JSON messages as defined on lines 17 and 43 and following. In order to log all the sent and received HTTP messages, I simply changed the isMessageToLog(log) function to always return true. After redeploying the script (disabling and enabling) it would log all HTTP messages.
My system has an app under an umbrella which starts up several GenServers, which on init make some dB calls, and thus get their own connection.
The problem is that in my tests of a controller where I have inserted some records into the dB, the controller makes a call to one of those GenServers, which then does some more dB queries. But since it is a different sandbox, it does not see the records.
I am looking for a solution in general that would allow existing, running GenServers to use the same sandbox as the test. I would greatly appreciate any ideas. I tried adding the following right after the sandbox checkout in the test setup, but didn't help:
Ecto.Adapters.SQL.Sandbox.allow(MyApp.Repo, self(), Some.GenServer)
The only working solution I found was to allow the GenServer to be started with an alternate name, starting it up thus using the same sandbox db connection as the test, having my controller use this differently named version, and shutting it down right before the end of the test.
Seems that I ended up with the same issue.
My solution was to keep the default Phoenix settings, and terminate and restart my process before each test, like this:
setup(%{conn: conn}) do
Supervisor.terminate_child(Some.Supervisor, Some.GenServer)
Supervisor.restart_child(Some.Supervisor, Some.GenServer)
{:ok, conn: conn}
end
Tests SHOULD NOT be async: true
I use NSTask to run my helper application. On 99% one my customer systems this works fine, but two got back to me letting me know it doesn't. One of them was nice enough to let me look into the issue per remote desktop.
I tried a lot of different NSPipe/NSFileHandle combination for StandardOutput/StandardError to make sure the problem is not related filling up these buffers. Example 1 and 2. My guess is that it is not related because it works fine on so many systems and _dyld_start is too early on in the application lifecycle to fill up StandardOutput/StandardError.
Other notes about the problem:
Launching the helper app from the terminal works fine.
Attaching and detaching the gdb on the stuck process and after-worth it works fine and when it finished NSTask picks up work after -waitUntilExit.
Using fork(2) and execv(3) instead of NSTask is able to launch and run the helper fine.
The parent process is sandboxed but I think previous reports where non-sandboxed on Mac OS X 10.6/10.7.
Screenshot of the process Sample from Activity Monitor:
Any clues or debugging tips to figure out why the helper is stuck in _dyld_start are welcome!
Since nobody answered, I am throwing a few ideas. Maybe one of them is the answer – only guessing – but since clues and tips are welcome, you could take a look at:
the list of the loaded libraries in the crash dump (there may be a clue there)
any error that would happen in the child process (after the fork). However, I see why it could be difficult to get back any post-fork error.
If I recall correctly, NSTask calls posix_spawn(2). This may be a clue, since using fork(2) and execv(3) seems working, you could focus on the differences between NSTask and the non-blocking alternative. Clearly, something is happening at the very beginning that prevents the child from executing properly.
Are you sure it is stuck and not crashed? As far as the user could tell, your app your app wouldn't look like it crashed. Only the child process would crash.
As a last resort, you could try to look for any Mach exception occuring (if
any, that would mean an error, which you wouldn't be able to
recover anyway. But it would provide valuable clues nonetheless).
You can tell willing custommers to send you their sysdiagnose. To this goal, ask them to hit Command + Option + Control + . + Shift to wait a few minutes. Soon after, their finder should pop a window to reveal a file named: sysdiagnose_timestamp_.tar.gz. Kindly ask them to mail it to you. Mine is around 5 MB. More details on the sysdiagnose man page.
I had to move a website on a bluehost server, that is in the Joomla Platform 1.7. I did alot of reasearch on Joomla.org and google and still haven't resloved the issue.
I recieve the following error: Infinite loop detected in JError. I went threw the configuration file and made sure that database and user match up with my new database parameters match up and I am still recieving this issue. Thank you. Urgent response will be very helpful. Currently working on this and this is not a good start. :(
I have ran into the same issue moving my Joomla site from one server to another. What I learned is the following;
Make sure you look at the parameters in configuration.php. Double check if the following variables in your configuration.php file is correct. (Double Check) You did mention that you already have done so. In that case I am 98% sure that you have an issue dealing with file Attributes with configuration.php. Change the Attributes of configuration.php from 444 to 666.
To get detailed information about the error, open the error.php file located in /libraries/joomla/error/ on your server.
In the following code:
public static function throwError(&$exception)
{
static $thrown = false;
// If thrown is hit again, we've come back to JError in the middle of
throwing
another JError, so die!
if ($thrown) {
// echo debug_print_backtrace();
jexit(JText::_('JLIB_ERROR_INFINITE_LOOP'));
}
change the line // echo debug_print_backtrace();
to the following:
**print"<pre>";
echo debug_print_backtrace();
print"</pre>";**
Remember- When you change the parameters in configuration.php to you new database make sure you that configuration.php file attribute is set to 666, Otherwise when you go to save the file it will not change. Try this first.. Good luck.