Studio6.1.2562 and virtual memory

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been getting some unexpected error messages from Studio6.1 when I run debug-sessions. (Jtag MkIII and UC3xxx processor)

"Atmel Studio was unable to start your debug session.
Please verify device selection, interface settings, target power and connections to the target device."

and
"Local backend agent has disconnected. Debugging will now be terminated"

The atbacked process consumes about 200Mbytes of virtual-memory every time my debug-session starts and doesn't release it when the debug-session stops.
This means that after a few debug sessions atbacked has used all the available virtual-memory and crashes with the above two error messages.

Fortunately this is just an annoyance, because Windows releases the virtual memory after atbackend has died and the parent atmelstudio process restarts atbacked

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just in case it helps there is a new SP1.1 around for a week or so.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Downloaded all 605Mb (grrrrrr) of Studio 6.1.2674 SP1 and things have.., uhhmmm.., changed.
Not improved., just changed.

Studio6 now crashes because atbackend does not crash when it has grabbed all the available virtual memory.

Sigh.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even though I haven't experienced any major disasters when using AS6 (not very often and on a separate computer) I'm sure happy to still use AS4.18. :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Mike,

I will try figure out where the crash comes from. Can you turn on diagnostic logging (Tools|Options|Tools), make the backend crash, and send me(PM) the backend agent output that comes in the Output pane when you select "Backend agent" in the drop down ?

Thanks, Dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I get a similar problem with a different error message.

Every time I start a debug-session, atbackend consumes about 350MB of normal and virtual memory and doesn't release it at the end. At about the 6th or 7th session the memory of atbackend is over 2GB. Then I get the error message:

"Failed to launch program.

Error: boost::thread_resource_error"

I'm using Win XP 32-bit with 4GB of RAM (actualy about 3,5 GB is addressed). My debug-tool is an AVR One, my target an AT32UC3C. I have the same error using Atmel Studio 6, 6.1 and actually 6.1.1 Build 2674.

While atbackend does the memory allocation, the status in Atmel Studio reads "Writing (0%)".

If needed I have recordings of a successful and a failed debug-session of the atbackend-output.

Hopefully there is a solution out there... :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have not gotten around to looking for the memory leak.

Do you break execution before ending debugging ? That might help.
Another tip is to reduce the debug info of your executables to -g2 or -g1. atbackend will leak less memory so you get more runs before needing to restart.

regards, Dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dan,

Thanks for your reply.

Breaking the execution before ending the debugging had no visible effect for me. atbackend's memory consumption didn't change.

-g2 did the trick for me right now. After about 10 starts this morning, atbackend's memory is still below 35MB. It looks like atbackend has a problem with -g3 on my computer.

I keep you informed, if anything changes ;-)

Good luck finding the memory hole. If you need additional infos, don't hesitate to ask.

regards, Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zocholl wrote:

Good luck finding the memory hole. If you need additional infos, don't hesitate to ask.

I cannot get leaks out of my tests, it would be great to get your elf file,compiled with -g3, to try locate the leak.

Thanks, Dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The patch DLLs at https://www.avrfreaks.net/index.p... may fix this issue (or so they did for Markus)

Regards, Dan