My monodroid application builds and runs fine, but breakpoints are not being hit. This is both for physical devices and the emulator.
I created a new default monodroid application and it does hit break points.
I have tried rebuilding, restarting ADB, and rebooting. I am running VS2010, M4A version 4.0.1.
The android device logging screen gives the following (this covers 3 debug sessions)
Eye friendly version MonoDroid-Debugger Specific. EDIT Entire log as requested Full Log
*8:55 AM W 2477 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0i:8907,server=y,embedding=1
8:55 AM W 2477 MonoDroid-Debugger Accepted stdout connection: 36
9:19 AM W 2738 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transport=dt_socketjoglevel=0,address=127.0.01:8913,server=y,embedding=1
9:19 AM W 2738 MonoDroid-Debugger Accepted stdout connection: 36
9:27 AM W 2803 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transport=dt_socketjoglevel=0,address=127.0.Oi:8915,server=y,embedding=1
9:27 AM W 2803 MonoDroid-Debugger Accepted stdout connection: 36
9:27 AM W 2838 MonoDroid-Debugger Not starting the debugger as the timeout value has been reached; current-time: 1326468477 timeout 1326468463
9:29 AM W 2878 MonoDroid-Debugger Not starting the debugger as the timeout value has been reached; current-time: 1326468544 timeout 1326468463
9:29 AM W 2896 MonoDroid-Debugger Not starting the debugger as the timeout value has been reached; current-time: 1326468544 timeout 1326468463
9:29 AM W 2923 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transport=dt_socketjoglevel=0,address=127.0.01:8901,server=y,embedding=1
9:29 AM W 2923 MonoDroid-Debugger Accepted stdout connection: 36
9:29 AM W 2959 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transport=dt_socketloglevel=0,address=12700.1:8901,server=y,embedding=1
9:29 AM W 2959 MonoDroid-Debuqqer Accepted stdout connection: -1
9:29 AM W 2982 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transpoft=dt_socketjoglevel=0,address=127.0.0i:8903,sen’er=y,embedding=l
9:29 AM W 2982 MonoDroid-Debugger Accepted stdout connection: 37
9:30 AM W 3038 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8963,server=y,embedding=1
9:30 AM W 3038 MonoDroid-Debugger Accepted stdout connection: 36
9:32 AM W 3071 MonoDroid-Debugger Not starting the debugger as the timeout value has been reached; current-time: 1326468730 timeout: 1326468676
9:32 AM W 3113 MonoDroid-Debugger Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8965,server=y,embedding=1
9:32 AM W 3113 MonoDroid-Debugger Accepted stdout connection: 37*
Following the advice given here I took a look inside the apk and I do see .mdb files.
Thanks in advance for any insight.
I installed Mono for Android 4.0.3 and everything is back to normal. This doesn't really pin down what was broken... but I'll live with it. Thanks for your help jpobst.
Related
I've written a simulator, which is distributed over two hosts. When I launch a few thousand processes, after about 10 minutes and half a million events written, my main Erlang (OTP v22) virtual machine crashes with this message:
no next heap size found: 18446744071789822643, offset 0.
It's always that same number - 18446744071789822643.
Because my server is very capable, the crash dump is also huge and I can't view it on my headless server (no WX installed).
Are there any tips on what I can look at?
What would be the first things I can try out to debug this issue?
First, see what memory() says:
> memory().
[{total,18480016},
{processes,4615512},
{processes_used,4614480},
{system,13864504},
{atom,331273},
{atom_used,306525},
{binary,47632},
{code,5625561},
{ets,438056}]
Check which one is growing - processes, binary, ets?
If it's processes, try typing i(). in the Erlang shell while the processes are running. You'll see something like:
Pid Initial Call Heap Reds Msgs
Registered Current Function Stack
<0.0.0> otp_ring0:start/2 233 1263 0
init init:loop/1 2
<0.1.0> erts_code_purger:start/0 233 44 0
erts_code_purger erts_code_purger:wait_for_request 0
<0.2.0> erts_literal_area_collector:start 233 9 0
erts_literal_area_collector:msg_l 5
<0.3.0> erts_dirty_process_signal_handler 233 128 0
erts_dirty_process_signal_handler 2
<0.4.0> erts_dirty_process_signal_handler 233 9 0
erts_dirty_process_signal_handler 2
<0.5.0> erts_dirty_process_signal_handler 233 9 0
erts_dirty_process_signal_handler 2
<0.8.0> erlang:apply/2 6772 238183 0
erl_prim_loader erl_prim_loader:loop/3 5
Look for a process with a very big heap, and that's where you'd start looking for a memory leak.
(If you weren't running headless, I'd suggest starting Observer with observer:start(), and look at what's happening in the Erlang node.)
Recently bought gy bme280 and trying to connect it with the Esp8266 Nodemcu V3 Esp 12.
Followed the instructions here for the hookup and then for the code, followed this tutorial.
I built the firmware from https://nodemcu-build.com/ a couple of days ago from master.
The debug logs shows this
Queue empty
Running
Function platform_gpio_mode() is called. pin_mux:1610614844, func:0
Function platform_gpio_mode() is called. pin_mux:1610614848, func:0
i2c setup result --> 100000
mode: b7
humidity oss: 5
config: f0
No ACK on address: 76
No ACK on address: 77
bme280 setup result -->
nil
pm open,type:2 0
My code
srv = net.createServer(net.TCP)
scl = 1
sda = 2
i2cResult = i2c.setup(0, sda, scl, i2c.SLOW) -- call i2c.setup() only once
print("i2c setup result --> " .. i2cResult)
local bmeResult = bme280.setup()
print("bme280 setup result --> ")
print(bmeResult)
The connections between BME280 and ESP8266 I have are
SDO -> G
CSB -> 3V
SDA -> D2
SCL -> D1
VCC -> 3V
GND -> G
Any idea of what is failing or what else can I do to troubleshoot it?
I'm having difficulty getting ipcluster to start all of the ipengines that I ask for. It appears to be some sort of timeout issue. I'm using IPython 2.0 on a linux cluster with 192 processors. I run a local ipcontroller, and start ipengines on my 12 nodes using SSH. It's not a configuration problem (at least I don't think it is) because I'm having no problems running about 110 ipengines. When I try for a larger amount, some of them seem to die during start up, and I do mean some of them - the final number I have varies a little. ipcluster reports that all engines have started. The only sign of trouble that I can find (other than not having use of all of the requested engines) is the following in some of the ipengine logs:
2014-06-20 16:42:13.302 [IPEngineApp] Loading url_file u'.ipython/profile_ssh/security/ipcontroller-engine.json'
2014-06-20 16:42:13.335 [IPEngineApp] Registering with controller at tcp://10.1.0.253:55576
2014-06-20 16:42:13.429 [IPEngineApp] Starting to monitor the heartbeat signal from the hub every 3010 ms.
2014-06-20 16:42:13.434 [IPEngineApp] Using existing profile dir: u'.ipython/profile_ssh'
2014-06-20 16:42:13.436 [IPEngineApp] Completed registration with id 49
2014-06-20 16:42:25.472 [IPEngineApp] WARNING | No heartbeat in the last 3010 ms (1 time(s) in a row).
2014-06-20 18:09:12.782 [IPEngineApp] WARNING | No heartbeat in the last 3010 ms (1 time(s) in a row).
2014-06-20 19:14:22.760 [IPEngineApp] WARNING | No heartbeat in the last 3010 ms (1 time(s) in a row).
2014-06-20 20:00:34.969 [IPEngineApp] WARNING | No heartbeat in the last 3010 ms (1 time(s) in a row).
I did some googling to see if I could find some wisdom, and the only thing I've come across is http://permalink.gmane.org/gmane.comp.python.ipython.devel/12228. The author seems to think it's a timeout of sorts.
I also tried tripling (90 seconds as opposed to the default 30) the IPClusterStart.early_shutdown and IPClusterEngines.early_shutdown times without any luck.
Thanks - in advance - for any pointers on getting the full use of my cluster.
When I try execute ipcluster start --n=200 I get: OSError: [Errno 24] Too many open files
This could be what happens to you too. Try raising the open file limit of the OS.
I am currently trying to connect my DIY DC77 clock to ntpd (using Ubuntu). I followed the instructions here: http://wiki.ubuntuusers.de/Systemzeit.
With ntpq I can see the DCF77 clock
~$ ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+dispatch.mxjs.d 192.53.103.104 2 u 6 64 377 13.380 12.608 4.663
+main.macht.org 192.53.103.108 2 u 12 64 377 33.167 5.008 4.769
+alvo.fungus.at 91.195.238.4 3 u 15 64 377 16.949 7.454 28.075
-ns1.blazing.de 213.172.96.14 2 u - 64 377 10.072 14.170 2.335
*GENERIC(0) .DCFa. 0 l 31 64 377 0.000 5.362 4.621
LOCAL(0) .LOCL. 12 l 927 64 0 0.000 0.000 0.000
So far this looks OK. However I have two questions.
What exactly is the sign of the offset? Is .DCFa. ahead of the system clock or behind the system clock?
.DCFa. points to refclock-0 which is a DIY DCF77 clock emulating a Meinberg clock. It is connected to my Ubuntu Linux box with an FTDI usb-serial adapter running at 9600 7e2. I verified with a DSO that it emits the time with jitter significantly below 1ms. So I assume the jitter is introduced by either the FTDI adapter or the kernel. How would I find out and how can I reduce it?
Part One:
Positive offsets indicate time in the client is behind time on the server.
Negative offsets indicate that time in the client is ahead of time on the server.
I always remember this as "what needs to happen to my clock?"
+0.123 = Add 0.123 to me
-0.123 = Subtract 0.123 from me
Part Two:
Yes the USB serial converters add jitter. Get a real serial port:) You can also use setserial and tell it that the serial port needs to be low_latency. Just apt-get setserial.
Bonus Points:
Lose the unreferenced local clock entry. NO LOCL!!!!
I'm attempting to look at the memory of an app running on my iPad. I've got the pid of the app and I'm able to attach to the process with gdb.
iPad:~/dev root# gdb -p 3839
GNU gdb 6.3.50.20050815-cvs (Fri May 20 08:08:42 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=arm-apple-darwin9 --target=".
/private/var/root/dev/3839: No such file or directory
Attaching to process 3839.
0x35824004 in ?? ()
(gdb)
However, when i attempt to dump one of the memory regions:
(gdb) info mach-regions
Region from 0x22000 to 0x24000 (---, max r-x; copy, private, not-reserved)
... from 0x24000 to 0x269000 (---, max r-x; copy, private, not-reserved)
[...]
... from 0x267a000 to 0x267b000 (---, max rwx; copy, private, not-reserved)
... from 0x267b000 to 0x267c000 (---, max rwx; copy, private, not-reserved)
... from 0x267c000 to 0x267d000 (---, max rwx; copy, private, not-reserved)
... from 0x267d000 to 0x267f000 (---, max rwx; copy, private, not-reserved)
... from 0x267f000 to 0x2680000 (---, max rwx; copy, private, not-reserved)
[...]
(gdb) dump binary memory output.bin 0x267c000 0x267d000
I get this error:
gdb stack crawl at point of internal error:
0 gdb 0x00170e74 internal_vproblem + 124
1 gdb 0x0016dd68 internal_verror + 52
2 gdb 0x0016dd94 align_down + 0
3 gdb 0x0016def8 gdb_check_fatal + 36
4 gdb 0x001eba9c mach_xfer_memory + 588
5 gdb 0x000c7ca8 default_xfer_partial + 256
6 gdb 0x000ca04c target_xfer_partial + 1004
7 gdb 0x000ca404 target_read_partial + 56
8 gdb 0x000ca488 target_read + 120
9 gdb 0x000ca674 target_read_memory + 68
10 gdb 0x00003f5c dump_memory_to_file + 276
11 gdb 0x0016c804 execute_command + 1160
12 gdb 0x000aba88 command_handler + 228
13 gdb 0x000acd94 command_line_handler + 768
14 gdb 0x002236b4 rl_callback_read_char + 160
../../gdb-1518/src/gdb/macosx/macosx-nat-mutils.c:772: internal-error: assertion failure in function "mach_xfer_memory": r_end >= cur_memaddr
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
At which point the app crashes as well, once I exit gdb.
It seems like I'm doing everything right, here... why is the error happening? And how would one go about making it work?
I'm running iOS 5.1.1 on the first generation iPad.
Ah apparently the version of GDB that ships with Cydia doesn't work on iOS 5. These instructions worked for me:
GNU Debugger (gdb) is used to analyze the run time behavior of an iOS application. In recent iOS versions, GNU Debugger directly downloaded from the Cydia is broken and not functioning properly. Following the Pod 2g blog post also did not help me.
To get rid of this problem, add http://cydia.radare.org to cydia source and download the latest GNU Debugger (build 1708). GDB build 1708 is working for iOS 5.x.