Main Site Documentation

EMX freezes after Garbage Collection

#1

Hi,

I am using EMX version 4.2.9.0. I have found that sometimes when GC occurs i get this strange RAMC messages after GC, the device then become non responsive and i have to reboot it to get it going again. This has happened on all the devices i have tested (around 10). Could you please let me know how this occurred.


GC: 151msec 383304 bytes used, 6956364 bytes available
Type 0F (STRING              ):  35364 bytes
Type 11 (CLASS               ): 100752 bytes
Type 12 (VALUETYPE           ):   6036 bytes
Type 13 (SZARRAY             ): 137556 bytes
  Type 03 (U1                  ):  81636 bytes
  Type 04 (CHAR                ):    444 bytes
  Type 07 (I4                  ):   7020 bytes
  Type 0F (STRING              ):     24 bytes
  Type 11 (CLASS               ):  48348 bytes
  Type 12 (VALUETYPE           ):     84 bytes
Type 15 (FREEBLOCK           ): 6956364 bytes
Type 17 (ASSEMBLY            ):  47184 bytes
Type 18 (WEAKCLASS           ):    672 bytes
Type 19 (REFLECTION          ):   7284 bytes
Type 1B (DELEGATE_HEAD       ):   1800 bytes
Type 1C (DELEGATELIST_HEAD   ):     96 bytes
Type 1D (OBJECT_TO_EVENT     ):    648 bytes
Type 1E (BINARY_BLOB_HEAD    ):  17160 bytes
Type 1F (THREAD              ):   5760 bytes
Type 20 (SUBTHREAD           ):    768 bytes
Type 21 (STACK_FRAME         ):  13788 bytes
Type 22 (TIMER_HEAD          ):     72 bytes
Type 26 (WAIT_FOR_OBJECT_HEAD):    240 bytes
Type 27 (FINALIZER_HEAD      ):    624 bytes
Type 28 (MEMORY_STREAM_HEAD  ):     36 bytes
Type 29 (MEMORY_STREAM_DATA  ):    396 bytes
Type 2A (SERIALIZER_HEAD     ):     96 bytes
Type 2B (SERIALIZER_DUPLICATE):   1776 bytes
Type 2C (SERIALIZER_STATE    ):   1200 bytes
Type 31 (IO_PORT             ):    216 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):   3708 bytes
RAMC CRC:a66e8dfc!=d5ba76e1
RAMC 00:eaffffff
RAMC 04:e59ff010
RAMC 08:baadf00d
RAMC 0c:e59ff00c
RAMC 10:e59ff00c
RAMC 14:baadf00d
RAMC 18:e59ff008
RAMC
#2

What does your code look like?

#3

Please post some code. I’ve been using cg without any problems with emx and sdk v4.2.9.0

#4

I’ve never seen this before. RAMC CRC may indicate that your RAM is corrupted. May be you should reflash your EMX.

#5

It’s interesting that you can repro this on all 10 devices, so you should be able to have someone else also repro it with your code (if you’re willing to share). I’m not a search index of this site, but it seems like this isn’t something that’s come up before, at least not very often!

#6

No news about this issue?

#7

Waiting for a code sample

#8

Hi All,

I have been working with Evan on the GC freezing and locking issue and have been able to replicate it in an easily distributed solution.

I have a solution which i use for testing and profiling network communications, so i set up a while loop connecting to an unavailable IP address which of course would block indefinitely so i put a constraint exception of 2 secs around it and found that after 40 attempts it then threw a socket exception with the error of 10055 so i thought when that occurs i could try and force GC and that is when the lock up occurred.

I have zipped up the solution and put it up on drop box for you to view, its just basically a test platform i used to test timings between various settings and transports.

In my testing here on our custom EMX board and Spider i got the lock up on the 41st iteration using v4.2.9 firmware

Hopefully you all get the same!

#9

I do not have the 4.2.9 sdk, I am still running the 4.2.7 one and will not have time to check on this release. May be someone else?

#10

TheScruba - Hi, I downloaded and ran your program on my EMX and can confirm I have the same issue and outcome using v4.2.9 firmware.

Would be interested to know what results GHI have got?

#11

We have downloaded the code and have started looking into the problem.

#12

We are continuing to look into this, but as a workaround until we can determine if there is an issue, can you place a Thread.Sleep(1) at the bottom of ConstraintTest()? This seemed to work for us.

We were able to replicate the issue, but only without any calls to Sleep() inside the loop.

#13

Yeap,

if the speed is not your problem, I think it is safer if we add thread.sleep(x) in any while loop.

Example we are waiting for a button is pressed:

I like this way: )

So the processor can do something else and in some case, the app will run smoother :)))

Anyway, we will look into it to see what we can do.

#14

I dont really understand why you mean with this, bottom of ConstraintTest will be outside any of the loops.

I tried putting one before uninstalling the constraint as seen below


while ( true ) {
			
				try {
				

					Debug.Print("********** Socket Test " + i++ + " **********");
                    
					ExecutionConstraint.Install(2000, 0);

					ConnectSocket( "192.168.0.18", 1234, false );
                    Thread.Sleep(10);

					ExecutionConstraint.Install(-1, 0);
				
				} catch ( ConstraintException ) {

					Debug.Print("********** Constaint Exception on Test " + i + " **********");
				
				}

I also tried with the sleep before the call to GC as seen below


	} catch ( ConstraintException ) {

					Debug.Print("********** Constaint Exception on Test " + i + " **********");
				
				}
			
			
				if ( i == 42 )

					break;
			
			}
                        Thread.Sleep(10); 
			Debug.GC	( true );

Both of these attempts still caused the system to freeze.

#15

@ Evan Khizkial -

it should be inside while loop and make sure it is executed. In your case maybe some commands threw an exception then thread.sleep was ignored.


while (true)
{
      Thread.sleep(10);  // ============> here
      try
      {
       // your code
       }
     catch
      {
      }
}

or


while (true)
{
     
      try
      {
       // your code
       }
     catch
      {
      }
       Thread.sleep(10);  // ============> here
}
#16

Hi Dat,

With this addition of the sleep within the socket creation loop, is this to allow GC to run itself in the background before the application, once it breaks out of the while loop, manually forces it to run?

#17

@ Chris_MC - maybe but we need to know if this fixed the issue on your end please.

#18

Hi Gus,

Yes inserting the sleep appeared to solve the lockup.

I may have experienced this in my own application. Though it is quite large in size, so trying to track down exactly what part of the program it happens in might be more difficult. But I’m nearly sure all my processing loops have sleeps in them.

Knowing the reason behind the lockup on GC would be great. I don’t have in depth knowledge on GC, but if the sleep is allowing the GC to run in the background, maybe is that it has a problem when there are a number of objects to dispose of at the same time?

#19

@ Chris_MC -

talking about garbage collection means we are talking about quite deep inside processor where no one programmer want to touch on that. :))

In my point, GC is always called automatically whenever the memory of system goes low, it doesn’t matter sleep or not sleep in there.Do not worry too much about GC.

#20

Hi Dat,

Yes, Garbage Collection is definitely something I’d rather treat as a blackbox for the most part!

It’s more the issue as to why the emx is locking up that I want to get to the bottom of.