Memguard

8 posts / 0 new
Log in or register to post comments
Last post
Mon, 2012-08-20 19:07
#1
JosDuchIt
JosDuchIt's picture
Offline
Last seen: 6 years 4 months ago
Joined: 2012-01-08 20:57
Memguard
Where could i find explanations on the ourput Memguard produces?
Top
Tue, 2012-08-21 11:07
tboeckel
tboeckel's picture
Offline
Last seen: 2 years 9 months ago
Joined: 2011-09-13 12:32
This is the very first
This is the very first paragraph of MemGuard's "documentation": 
  1. MemGuard is a MungWall/WipeOut/MuGuardianAngel-like program that munges
  2. memory and watches illegal memory allocations and releases. As I'm too
  3. lazy to write a proper documentation;), you should be familiar with one
  4. of the programs mentioned above. MemGuard is written for use with Amiga
  5. OS4.
Shouldn't this ring a bell to take a look in the docs of the mentioned programs? Wipeout's docs contain all the necessary information.
Top
Tue, 2012-08-21 12:51
(Reply to #2)
JosDuchIt
JosDuchIt's picture
Offline
Last seen: 6 years 4 months ago
Joined: 2012-01-08 20:57
@tboeckel Thanks, I noted
@tboeckel Thanks, I noted that too and I did consult Wipeout doc before posting the question. It still does not explain much of the output you get (even when i run sashimi too) I was hoping more guidance would exist somewhere. Did not find it with extensive internet searching though. Do i have to learn asm to understand the output? What are the different output sections corresponding to one hit? If an illegal memory alloc is mentioned, can the given info help me to find the source line?
Top
Tue, 2012-08-21 14:26
(Reply to #3)
kas1e
kas1e's picture
Offline
Last seen: 5 months 1 week ago
Joined: 2010-11-30 15:30
@JosDuchIt Just post the
@JosDuchIt Just post the output lines which you didn't understand and some of us can explain them. As for the source lines, its usually can be find by the addr2line (if the binary was compiled with -gstabs). Check that topic, maybe it will give you some more info about.
Top
Tue, 2012-08-21 18:32
(Reply to #4)
JosDuchIt
JosDuchIt's picture
Offline
Last seen: 6 years 4 months ago
Joined: 2012-01-08 20:57
@kas1e Here is an output in
@kas1e Here is an output in which i even did not had my program under test (Gui4Cli or gui4 its launcher)running I could relate the recurrent "Date" hit to TitleClock which was in my WBStartup , although not really used in the WBTitle and unchecked in the WBStartUp list. It may be that the "Wait" hit comes from there too. I have been plagued at startup with console oputput telling me that Date was made resident, and i also observed that for wait (although really just recently once) I expect both to be gone now, since i deleted TitkleClock entirely from WBSatrtUp. OK that's the context I did visit the thread, which was usefull indeed. Now following a 'Date' hit in the output beneath: - i understand first 2 lines, - then comes a list 8: 16: 24: 32 memory addresses of which 13 seem to be explained in the 13 lines below (how were they generated, how was the selection done producing the 13 adresses retained?) - these 13 lines ----> point to 'segments' & offsets . my understanding is that segments refer to how the executable is stored on disk 'segments' that ar loaded as a list probably too at thememory adresses given just after the arrow From Wipeout doc i guess 'Segtracker' can transform that in usable info??? but i also think segtracker only works under OS3.x - then 4 lines 
  1. LRa   01640f64 : "Kickstart/newlib.library.kmod" segment 0000 offset 2d20
  2. CTRa  6f975950 : "memguard" segment 0005 offset 8948
  3. LR    01641020 : "Kickstart/newlib.library.kmod" segment 0000 offset 2ddc
  4. CTR   6f9759c8 : "memguard" segment 0005 offset 89c0
Contrary to the example in other thread we have an additional LRa & CTRa ??? Here too LR(a) does not point to some 'Date' address (not to DOS either). Does it mean Date is OK? Then why rhe hit ?? The Stack backtrace ressembles grimreaper crashlog output except how addresses are given (Segtracker needed to deconde them?) Then a disassembly for which you obviously need to understand assembler code. (Or you could write a simple translation table to a more verbose pseudo command, starting with most common commands, maybe such a list exists?) And finally stuff i don't understand and how it could help me. Anyway, clarifying these, as well as relations betweeen sections that i missed, would be interesting, not only to me. Simplifying the output automatically to just what can be used directly with other tools say addr2line (eg with a Gui4Cli script) would then be possible. Thanks for any additional clarification? If this is possible, i wouldn't mind this text being corrected and expanded. 
  1. MemGuard 1.15 (2.1.2009) installed.
  2.  
  3. MEMGUARD HIT - [7] "Date" (5a7a39b0)
  4. rear wall damaged -- 596561B0 = AllocVec(24, 00001000)
  5.  0: 01641004 5976cd70 00000000 01ca97c4 596561b0 0002f030 01daa360 01daa3d4
  6.  8: 48442082 6f9759c8 016400ac 80000017 01ca97c4 5965e1b0 00000000 5c30a990
  7. 16: 599df040 6fce23bc 00000002 01e70000 01e70000 5a18d680 01e70000 00000000
  8. 24: 00000002 5ff9f000 0000002c 599df040 00000018 596561b0 5a185680 5a185654
  9. ----> 01641004 : "Kickstart/newlib.library.kmod" segment 0000 offset 2dc0
  10. ----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
  11. ----> 01daa360 : "Kickstart/kernel" segment 0001 offset 14a35c
  12. ----> 01daa3d4 : "Kickstart/kernel" segment 0001 offset 14a3d0
  13. ----> 6f9759c8 : "memguard" segment 0005 offset 89c0
  14. ----> 016400ac : "Kickstart/newlib.library.kmod" segment 0000 offset 1e68
  15. ----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
  16. ----> 6fce23bc : "C:Date" segment 0005 offset 03b4
  17. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  18. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  19. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  20. ----> 5a185680 : "C:Date" segment 0004 offset 0028
  21. ----> 5a185654 : "C:Date" segment 0004 offset fffffffc
  22. LRa   01640f64 : "Kickstart/newlib.library.kmod" segment 0000 offset 2d20
  23. CTRa  6f975950 : "memguard" segment 0005 offset 8948
  24. LR    01641020 : "Kickstart/newlib.library.kmod" segment 0000 offset 2ddc
  25. CTR   6f9759c8 : "memguard" segment 0005 offset 89c0
  26.  
  27. Stack backtrace:
  28. ----> 01641020 : "Kickstart/newlib.library.kmod" segment 0000 offset 2ddc
  29. ----> 016410a4 : "Kickstart/newlib.library.kmod" segment 0000 offset 2e60
  30. ----> 6fce2104 : "C:Date" segment 0005 offset 00fc
  31. ----> 0151894c : "Kickstart/dos.library.kmod" segment 0000 offset 22a08
  32. ----> 0143af48 : "Kickstart/kernel" segment 0000 offset 3af44
  33. ----> 0143afc8 : "Kickstart/kernel" segment 0000 offset 3afc4
  34.  
  35. Disassembly:
  36.  0164101c: 4e800421	bctrl
  37.  01641020: 7eadab78	mr	r13,r21
  38.  01641024: 4bfff8a8	b	0x16408CC
  39.  01641028: 9421ffc0	stwu	r1,-64(r1)
  40.  0164102c: 7c0802a6	mflr	r0
  41.  
  42. MEMGUARD HIT - [8] "Date" (5a7a41c0)
  43. rear wall damaged -- 59658720 = AllocVec(24, 00001000)
  44.  0: 01641004 59780d70 00000000 01ca97c4 59658720 0002f030 01daa360 01daa3d4
  45.  8: 48442082 6f9759c8 016400ac 80000017 01ca97c4 59660720 00000000 5c30a990
  46. 16: 599d56c0 6fce23bc 00000002 01e70000 01e70000 5a18d680 01e70000 00000000
  47. 24: 00000003 5ff9f000 0000002c 599d56c0 00000018 59658720 5a185680 5a185654
  48. ----> 01641004 : "Kickstart/newlib.library.kmod" segment 0000 offset 2dc0
  49. ----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
  50. ----> 01daa360 : "Kickstart/kernel" segment 0001 offset 14a35c
  51. ----> 01daa3d4 : "Kickstart/kernel" segment 0001 offset 14a3d0
  52. ----> 6f9759c8 : "memguard" segment 0005 offset 89c0
  53. ----> 016400ac : "Kickstart/newlib.library.kmod" segment 0000 offset 1e68
  54. ----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
  55. ----> 6fce23bc : "C:Date" segment 0005 offset 03b4
  56. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  57. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  58. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  59. ----> 5a185680 : "C:Date" segment 0004 offset 0028
  60. ----> 5a185654 : "C:Date" segment 0004 offset fffffffc
  61. LRa   01640f64 : "Kickstart/newlib.library.kmod" segment 0000 offset 2d20
  62. CTRa  6f975950 : "memguard" segment 0005 offset 8948
  63. LR    01641020 : "Kickstart/newlib.library.kmod" segment 0000 offset 2ddc
  64. CTR   6f9759c8 : "memguard" segment 0005 offset 89c0
  65.  
  66. Stack backtrace:
  67. ----> 01641020 : "Kickstart/newlib.library.kmod" segment 0000 offset 2ddc
  68. ----> 016410a4 : "Kickstart/newlib.library.kmod" segment 0000 offset 2e60
  69. ----> 6fce2104 : "C:Date" segment 0005 offset 00fc
  70. ----> 0151894c : "Kickstart/dos.library.kmod" segment 0000 offset 22a08
  71. ----> 0143af48 : "Kickstart/kernel" segment 0000 offset 3af44
  72. ----> 0143afc8 : "Kickstart/kernel" segment 0000 offset 3afc4
  73.  
  74. Disassembly:
  75.  0164101c: 4e800421	bctrl
  76.  01641020: 7eadab78	mr	r13,r21
  77.  01641024: 4bfff8a8	b	0x16408CC
  78.  01641028: 9421ffc0	stwu	r1,-64(r1)
  79.  0164102c: 7c0802a6	mflr	r0
  80. Dump of context at 0x7fe7d000
  81. Trap type: DSI exception
  82. Machine State (raw): 0x2f030
  83. Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on] 
  84. Instruction pointer: 0x1412624
  85. Crashed process:  (0x5a506390)
  86.  0: a9abadaf 5a4c3080 00000000 59656fdc 59656fdc 00000000 000000a0 01ca97c4
  87.  8: 5a4c3140 00000001 00001000 999b9d9f 28424084 5a4fa194 00000005 00000000
  88. 16: 5a4c3400 48424024 01c245c4 01dc0000 00000000 01dbd7f6 00000010 00001000
  89. 24: 00000000 01dc0000 00000000 7fff86c0 00000000 59656fdc 59656fd0 01ca97c4
  90. CR: 48424048   XER: 20000002  CTR: 01412640  LR: 0142a1d8
  91. ESR: 00000000
  92. DEAR: 999b9d9f
  93. mcsrr0: 0x0
  94. csrr0: 0x0
  95.  
  96. Disassembly of crash site:
  97.  01412614: 39600000   li                r11,0
  98.  01412618: 7f801800   cmpw              cr7,r0,r3
  99.  0141261c: 419e001c   beq-              cr7,0x1412638
  100.  01412620: 81630000   lwz               r11,0(r3)
  101. >01412624: 800b0000   lwz               r0,0(r11)
  102.  01412628: 90030000   stw               r0,0(r3)
  103.  0141262c: 812b0000   lwz               r9,0(r11)
  104.  01412630: 800b0004   lwz               r0,4(r11)
  105.  01412634: 90090004   stw               r0,4(r9)
  106.  01412638: 7d635b78   mr                r3,r11
  107. Fault caused by load operation
  108.  
  109. Registers pointing to code:
  110. r7 : module Kickstart/kernel at 0x01CA97C4 (section 1 @ 0x497C8)
  111. r18: module Kickstart/intuition.library.kmod at 0x01C245C4 (section 2 @ 0x4C48)
  112. r19: module Kickstart/kernel at 0x01DC0000 (section 1 @ 0x160004)
  113. r21: module Kickstart/kernel at 0x01DBD7F6 (section 1 @ 0x15D7FA)
  114. r25: module Kickstart/kernel at 0x01DC0000 (section 1 @ 0x160004)
  115. r31: module Kickstart/kernel at 0x01CA97C4 (section 1 @ 0x497C8)
  116. ip : module Kickstart/kernel at 0x01412624 (section 0 @ 0x12628)
  117. lr : module Kickstart/kernel at 0x0142A1D8 (section 0 @ 0x2A1DC)
  118. ctr: module Kickstart/kernel at 0x01412640 (section 0 @ 0x12644)
  119.  
  120. Stack Backtrace:
  121.  
  122. MEMGUARD HIT - [13] "Wait" (5a1c44c0)
  123. front wall damaged -- 5A2E1CE0 = AllocVec(32, 00011000)
  124.  0: 20000000 59780f10 00000000 01ca97c4 5a2e1ce0 0002f030 00000034 01ca97c4
  125.  8: 01e70000 20000000 596c2510 6f9759c8 44444024 00000000 00000000 5a44ee60
  126. 16: 01e70000 7fe6b4d0 01e70000 00010000 5a8639b0 5a2ef760 0143b0a0 5a2e1ce0
  127. 24: 5969dc50 00003166 0037445c 5969dd10 5969de90 00000000 01e70000 5a2e1ce0
  128. ----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
  129. ----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
  130. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  131. ----> 6f9759c8 : "memguard" segment 0005 offset 89c0
  132. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  133. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  134. ----> 0143b0a0 : "Kickstart/kernel" segment 0000 offset 3b09c
  135. ----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
  136. LRa   0151c174 : "Kickstart/dos.library.kmod" segment 0000 offset 26230
  137. CTRa  6f975950 : "memguard" segment 0005 offset 8948
  138. LR    0151acfc : "Kickstart/dos.library.kmod" segment 0000 offset 24db8
  139. CTR   6f9759c8 : "memguard" segment 0005 offset 89c0
  140.  
  141. Stack backtrace:
  142. ----> 0151acfc : "Kickstart/dos.library.kmod" segment 0000 offset 24db8
  143. ----> 6f99d2f8 : "C:Wait" segment 0004 offset 02f0
  144. ----> 0151894c : "Kickstart/dos.library.kmod" segment 0000 offset 22a08
  145. ----> 0143af48 : "Kickstart/kernel" segment 0000 offset 3af44
  146. ----> 0143afc8 : "Kickstart/kernel" segment 0000 offset 3afc4
  147.  
  148. Disassembly:
  149.  0151acf8: 4e800421	bctrl
  150.  0151acfc: 81410024	lwz	r10,36(r1)
  151.  0151ad00: 83a10014	lwz	r29,20(r1)
  152.  0151ad04: 83c10018	lwz	r30,24(r1)
  153.  0151ad08: 7d4803a6	mtlr	r10
Top
Fri, 2012-08-24 22:43
(Reply to #5)
kas1e
kas1e's picture
Offline
Last seen: 5 months 1 week ago
Joined: 2010-11-30 15:30
Did i understand right, that

Did i understand right, that your output posts are just from using of "c:date" ? (which lately involved "c:wait") ? I.e. its not about your programm at all, just default os4 binaries ? If so, then you can forget about addr2line, because addr2line use debug information included in the binary (which injects to binary if it compiled with -gstabs and co flags), and which more lucky dind't included in the os4 default bins (to reduce size). If you trying to detect the bug in the programm to which you have no sources and which contain no debug info, then you 100% forced to some interactive debugger (like GDB), or just disassemble whole binary (via objdump for example, or , if not on os4, then there is some better ways like by IDA on windows/linux), but assembler knowlege are must. That can be mess from the mess, and you can loose a looot of time to understand logic of programm, only to locate (maybe) where is bug and how to fix it (and lately make a patch for, as you didn't have sources of it). I.e. that possible, but you should have a lot of skills in reverse engenering (what mean knowing of assembler as well of course). As for memguard itself it looks like almost all the other tools of such a kind (even GR kind of close to it). I.e. they display the contents of most PPC registers at that time and to which file they belong (probably also symbols, when available). Then it follow a stack frame backtrace, which shows the call history. And a short disassembly of the error location. You can use the segment numbers and offsets to locate the code in the respective program, although as i already mentioned, tools like addr2line can only used with those offsets when you have included symbols in your program. When you cannot add symbols to a program, then you probably don't have its source anyway, so it make no big sense to find out the bug (if only you will going on hardcore way with all that reverse engenering stuff). Every part (stackbacktrace, disasemble, info of registers) have some tips as well (but they mostly never documented, and its all just you understand after a while). ===info of registers=== For example, by checking what data placed in the DAR register you can assume if it let's say NULL pointer crash or not. DAR its a one of ppc-cpu registers, Data Address Register. Another name of DAR is DEAR for sams). For example, if you will crashes with DAR = 000000xx then it usually mean that DAR shows the illegal access to address xx, caused by an access to NULL pointer + xx offset. So, you all the time can have a look firstly at DAR/DEAR, and by this you can make some assume about what kind of bug is it. As addon to that one of register may contain "ABADCAFE". Then that it. If DAR have let's say 0xDEADBEEF, thats about access to memory after its was freed, if 0xCCCCCCCC then its someting about Node (somethere on hp forum was sayd it happens when you have tried to free Node second time). That only about one register. Other registers can also bring you some info: address of return from function, address of parameters and all the stuff, just you need to have manual which show you what every register mean, and then understand it in real life what they offten mean and how they reacts (check links at bottom of my "step by step" article here). ===disassemble==== That one are pure assembler, and you of course better to know what is registers, to which and where and what placed because of that and that register (and again for brief tutorial you can check my article which i mention above). As in case with registers have some usuall "tips". Like for example, if you have LWZ (or kind) insturction, that mean something trying to load, if you see STW (or kind) that mean that something tryed to store. If take for example one of your disassemble parts: 

  1.  01412620: 81630000   lwz               r11,0(r3)
  2. >01412624: 800b0000   lwz               r0,0(r11)
Then i see that there is r3 used. r3 is always used by the ABI for parameters passing, and in all functions that use interfaces, the first parameter is the interface pointer. So in your code happens the following: 1). lwz r11,0(r3) - load a register (r11) with the contents of the address pointed to by the first parameter 2). lwz r0,0(r11) - and then load the r0 with the value pointed to by address it found there, which crashes (marker ">" at begining of line). The address seen in the DAR/DEAR register: 0x999b9d9f, which i assume illegal one. I.e. you not only need knowing of assembler to make result from it, but also know those little moments which you will find out only by tests / skills. =====stack backtrace ==== There is nothing which worth of discuss, as its just show what was called and from what, one by one, from bottom to top (or other way, not so matter). So if take for example that part: 
  1. Stack backtrace:
  2. ----> 0151acfc : "Kickstart/dos.library.kmod" segment 0000 offset 24db8
  3. ----> 6f99d2f8 : "C:Wait" segment 0004 offset 02f0
  4. ----> 0151894c : "Kickstart/dos.library.kmod" segment 0000 offset 22a08
  5. ----> 0143af48 : "Kickstart/kernel" segment 0000 offset 3af44
  6. ----> 0143afc8 : "Kickstart/kernel" segment 0000 offset 3afc4
There we see that kernel do something 2 times (called one function, that one call another one), then call something from dos.library, dos.library call c:wait, and c:wait call something from dos.library which happy crashes on 24b8 offset of 0000 segment . So there and dos.library can be tryed "addr2line" and "c:wait" itself, but only, if both have debug info (but i assume they not, because of reassons which i mean before). What about your questions in general:
- these 13 lines ----> point to 'segments' & offsets . my understanding is that segments refer to how the executable is stored on disk 'segments' that ar loaded as a list probably too at thememory adresses given just after the arrow From Wipeout doc i guess 'Segtracker' can transform that in usable info??? but i also think segtracker only works under OS3.x
Segments there mean sections of the binary constructed in the memory and offsets in them. Some time someone call section like segments, or segments like sections, but that is some terminology crap, and sometime its all messing around, so you just can think that its kind of the same. But if you worry about exact terminolyg, then there is relevant part from again, that "hacking way" article: ----- Although it may seem that sections and segments are the same thing, this is not the case. Sections are elements of the ELF file. When you load the file into memory, sections are joined to form segments. Segments are file elements too but they are loaded to memory and can be directly handled by the loader. So you can think of sections as segments, just you should know that segments are something that executes in memory, while sections is the material from which segments are built in memory. ------ Whole ELF binary contain bunch of sections/segments (depends if we refers to memory or to file, but let's it be the same for now), like .data (for data), .text (for code) and all bunch of other ones (but those 2 are important ones). The whole list of sections/segments you can find in the ELF specitication, or , again you can check my "hacking way" article where i explain how to hack ELF files, to get some begining stuff (+ links on necessary pdfs). With your example we have a references to segments 0000, 0001, 0004 and 0005 and offtets in them. Now you need to know what they mean: so you just again refer to books/specifications, or just use "readelf" from os4 sdk (which is better, because there can be os4 specific differences). For example, just "readelf -a c:date", and you will see what number of sections have. Segment 0001 mean .text (code), segment 0004 and 00005 mean different kind of data (.sdata and .sbss), and so on. Then, if you still feel you brave, you then can disassemble only necessary parts to which segments / offsets debug tools point out (by objdump or IDA as i say before). Through ts all will be pain because you have no debug info in those binaries, nor sources of them. But when its all about your own code, then all that info can be pretty helpfull (it can be helpfull of course and in case with debugging crashes in not your programs, just all will be harder) If you have any other questions about just ask.

Top
Sat, 2012-08-25 18:56
(Reply to #6)
JosDuchIt
JosDuchIt's picture
Offline
Last seen: 6 years 4 months ago
Joined: 2012-01-08 20:57
@kas1e Thanks a lot also for
@kas1e Thanks a lot also for your "hacking way " article and your proposal to help with more questions. I get some idea now of what i have to learn first in the debugging field (for difficult bugs freezes etc) I'll have more questions later. And no, i had no intention to look for bugs in Date or Wait: just a memguard output i had at hand.
Top
Tue, 2012-08-28 21:03
(Reply to #7)
kas1e
kas1e's picture
Offline
Last seen: 5 months 1 week ago
Joined: 2010-11-30 15:30
@JosDuchIT Just to add about
@JosDuchIT Just to add about memguard's LRa and CTRa. From memguard docs:
FAQ: Q: What's LRa, CTRa and PCa? A: 'a' stands for allocation. The shown value is the register contents at the time of the allocation.
So it's the value at the point of memory-allocation. And without 'a' it's seems at release- or accesss-time.
Top
Log in or register to post comments