Back
[00:43:57] <ferdna> can you guys tell me what the name of this standoff are?
[00:44:00] <ferdna> http://imgur.com/a/MRh0G
[00:44:17] <ferdna> CMFP 127-700-T40 Support Column
[00:44:20] <ferdna> is that the name?
[09:40:18] <rue_house> just pins, whats that from?
[12:42:21] <Levitator> Hrm. Doing some static initialization in C++. Seems to get overridden before main is called, somehow.
[12:42:39] <Levitator> Maybe there's an implicit register initialization after statics, but before main() is called.
[12:47:35] <yids> im trying to debug some avr code with simulavr and gdb, and was wondering if there is something handy in gdb that can tell me about memory usage, it seems like i run out of memory, is there a way to tel gdb to show me what is filling up the memory and how much memory there still is available?
[12:48:53] <bss36504> Levitator: What do you mean by static initialization? what are you statically initializing?
[12:49:16] <bss36504> yids: are you using a heap
[12:51:28] <Levitator> static members.
[12:52:34] <yids> uhm im still a bit in confused about how memory exactly works so I dont really now, but i use c and malloc, does that mean i use a heap?
[12:53:20] <bss36504> Levitator: I guess i dont understand the problem...are you trying to initialize something backed by a hardware register? Otherwise why would a register reset affect your static initialization?
[12:53:38] <bss36504> yids: Yeah if youre using dynamic memory allocation then you are using a heap.
[12:53:46] <bss36504> That's probably why you're running out of space
[12:53:48] <Levitator> Yeah, I have a member which performs a register init, and it doesn't take.
[12:53:59] <Levitator> If I move the init into main(), then it works.
[12:55:04] <yids> bss36504: hm but the fact that i use heap shouldnt be the reason that i run out right? just the fact that i use to much of the heap, right?
[12:55:13] <bss36504> Levitator: Can you share a snippet of the code that does that initialization? I might have an idea but I'm not 100% sure yet
[12:55:25] <bss36504> yids: Yes, that is correct.
[12:55:34] <bss36504> using it isnt a problem, using too much is
[12:56:24] <Levitator> It's just a register write that occurs before main. struct Singleton{ Singleton(){ write_some_registers(); } static Singleton instance; };
[12:56:54] <Levitator> I've confirmed that Singleton::Singleton() runs, but apparently the registers get overwritten by the runtime. That's how it acts, anyway.
[12:57:17] <yids> so is there an easy way in gdb to see what operations are filling up the heap? i would imagine that there would be something like a memory watcher that just tells you every time you allocate memory
[12:57:24] <bss36504> I guess I'm not 100% sure where the constructor gets called for statics.
[12:57:39] <Levitator> It's not well-defined other than that it happens before main
[12:57:53] <bss36504> yids: Such a tool would have overhead that probably wouldnt be desirable. So I'm guessing not.
[12:57:55] <Levitator> Their relative order is undefined, but it shouldn't matter unless the runtime is doing some magic.
[12:58:03] <bss36504> Levitator:
http://www.nongnu.org/avr-libc/user-manual/mem_sections.html
[12:58:08] <yids> and out of curiosity, what makes you think the problem lies in filling up the heap instead of the stack?
[12:58:08] <bss36504> Take a look at the Init sections.
[12:58:15] <bss36504> I imagine something is happening in there...
[12:58:44] <bss36504> yids: because the program space is linear so if you fill up the heap space it spills into the stack, which corrupts things.
[12:58:57] <bss36504> s/program/address
[12:59:24] <yids> but if you fill up the stack space it also spills into the heap right?
[13:00:13] <bss36504> Levitator:
http://stackoverflow.com/questions/1421671/when-are-static-c-class-members-initialized << seems to imply that static initialization is not really well defined beyond "sometime before main"
[13:00:48] <Levitator> Yeah, but, like I said, it shouldn't matter unless the runtime is interjecting something which conflicts.
[13:00:54] <bss36504> yids: are you using deep recursion or declaring tons and tons of variables?
[13:02:35] <yids> if by deep recursion you mean a lot functions calling functions etc then yes, also declaring quite some variables
[13:03:31] <bss36504> Levitator: I suppose thats true. Perhaps a better way of doing things is to make a "getInstance()" function on your singleton class. If the singleton member variable is null, construct a new one and call the init, if it's not null, just return the existing one.
[13:04:33] <bss36504> yids: Well then I suppose it could be just a stack overflow. No tool will really be able to detect that. You could always just read out the value of the stack pointer though.
[13:04:38] <Levitator> Yuck.
[13:04:52] <bss36504> Levitator: Well that's how a "traditional" singleton class is built
[13:05:00] <Levitator> Am writing an initialization queue to build a linked list.
[13:05:16] <bss36504> at least in java land
[13:05:24] <Levitator> Java is ew.
[13:05:54] <bss36504> Well regardless, the process I described is good practice no matter what language youre using
[13:05:58] <yids> hm so i would read the stack pointer value and check if its not being overwriten?
[13:06:19] <bss36504> yids: no you'd check to see that it's not near the end of the stack
[13:06:46] <bss36504> if after a bunch of nested function calls you see it start to approach the stack limit, you probably have a stack overflow problem
[13:07:31] <yids> how do I know what the stack limit is?
[13:07:45] <bss36504> yids: Read the datasheet for the part youre using?!
[13:08:35] <yids> ah
[13:30:07] <Tom_itx> you'll know it when you reach the end
[19:21:27] <Emil> Avr simulator, is there one?
[19:21:37] <Emil> That is free, for linux and you think good
[19:27:15] <Casper> all simulator suck, do not use them
[19:27:34] <Casper> if you find that one work well then it mean you are bad :D
[19:31:06] <Lambda_Aurigae> Emil, two out of three.
[19:31:25] <Lambda_Aurigae> simulavr