Hi.
I am halfway through writing a programme and when i try to debug it with Olly, a breakpoint i set doesn't hit as Olly claims that the breakpoint is on data even though it isn't. What could be causing this?
Thanks
Are you setting a breakpoint, then recompiling and then expecting the breakpoint to still trigger? In this case, the point in your program where the breakpoint was has changed and now the breakpoint is pointing at the middle of an instruction instead of the start.
If you're setting the breakpoint while debugging and it doesn't hit it then, we'll need some more information. Olly will display a message if you try and set a breakpoint on something that doesn't look like code, and I assume it uses the same logic to detect corrupt or invalid breakpoints at startup. Otherwise, using executable packers may have the same result. If you are using one, well, don't use it while you are debugging.
If you want to always have a breakpoint occur at the same place in your application, rather than setting it in Olly put an int 3 instruction in your code. (Just remember to take it out again :wink )
Cheers,
Zooba :U
Quote from: zooba on January 17, 2008, 08:17:05 AM
Are you setting a breakpoint, then recompiling and then expecting the breakpoint to still trigger? In this case, the point in your program where the breakpoint was has changed and now the breakpoint is pointing at the middle of an instruction instead of the start.
If you're setting the breakpoint while debugging and it doesn't hit it then, we'll need some more information. Olly will display a message if you try and set a breakpoint on something that doesn't look like code, and I assume it uses the same logic to detect corrupt or invalid breakpoints at startup. Otherwise, using executable packers may have the same result. If you are using one, well, don't use it while you are debugging.
If you want to always have a breakpoint occur at the same place in your application, rather than setting it in Olly put an int 3 instruction in your code. (Just remember to take it out again :wink )
Cheers,
Zooba :U
right. I know what you're saying but that's not the problem. I'll see if i can find an actual example
the source is this
parsehrd proc
pusha
lea edx,buf ;put origional text here as we will need to backtrack
lea edi, buf
mov al,020h
or cx,0ffffh
REPNE scasB ;find space which delimits sat name and first field
not ecx
dec ecx
jz badstr ; exit if space not found
push edi
lea edi, tempbuf
rep movsb ; copy name to tempbuf
pop edi
badstr:
popa
ret
parsehrd endp
olly translates it into
parsehrd > $ 60 PUSHAD
0040175A . 8D15 00404000 LEA EDX, DWORD PTR DS:[buf]
gettext > 8D DB 8D
settext > 3D DB 3D ; CHAR '='
00401762 . 00404000 DD OFFSET rotary.buf
00401766 B0 DB B0
00401767 20 DB 20 ; CHAR ' '
gettext > 66 DB 66 ; CHAR 'f'
settext > 83 DB 83
gettext > . C9 LEAVE
settext > . FFF2 PUSH EDX ; rotary.<ModuleEntryPoint>
0040176D . AE SCAS BYTE PTR ES:[EDI]
0040176E . F7D1 NOT ECX
00401770 . 49 DEC ECX
00401771 . 74 0A JE SHORT rotary.0040177D
00401773 . 57 PUSH EDI
00401774 . 8D3D FF404000 LEA EDI, DWORD PTR DS:[tempbuf]
0040177A . F3:A4 REP MOVS BYTE PTR ES:[EDI], BYTE PTR>
0040177C . 5F POP EDI ; rotary.00401100
0040177D > 61 POPAD
0040177E . C3 RETN
something is getting lost somewhere
I don't know what the problem is, but the way I work around it is by erasing the UDD file after each compliation and that seems to solve the problem. It may not be OLLY either that's at fault, it could be the linker because OLLY is afterall reading the PDB file when you use /debug /debugtype:both
The code compiles and debugs fine for me. However, I think Tight_Coder_Ex's solution will work, since you have some repeated labels in there. That generally suggests that you've debugged the executable before and then changed it.
So, either find and delete the UDD file (generally in OLLYDBG\UDD folder) or right-click in the CPU disassembly, choose the Analysis menu and remove both the analysis and the object scan. You will then probably need to restart Olly to get it back.
If you're using a custom batch file to compile, you can probably add a delete command in there to get rid of the UDD automatically. Olly apparently doesn't detect when the executable has changed - maybe this should be suggested for OllyDbg 2.0?
Cheers,
Zooba :U
Quote from: Tight_Coder_Ex on January 17, 2008, 04:38:12 PM
I don't know what the problem is, but the way I work around it is by erasing the UDD file after each compliation and that seems to solve the problem. It may not be OLLY either that's at fault, it could be the linker because OLLY is afterall reading the PDB file when you use /debug /debugtype:both
Hmm. there doesn't appear to be any UDD file, I am using radasm for the ide and the os is Vista if that contributes.
Quote from: zooba on January 18, 2008, 01:21:48 AM
The code compiles and debugs fine for me. However, I think Tight_Coder_Ex's solution will work, since you have some repeated labels in there. That generally suggests that you've debugged the executable before and then changed it.
yeah, it has been mucked around a lot
Quote
So, either find and delete the UDD file (generally in OLLYDBG\UDD folder) or right-click in the CPU disassembly, choose the Analysis menu and remove both the analysis and the object scan. You will then probably need to restart Olly to get it back.
thanks for that, the both of you. The udd file does seem to be the problem. what is the udd file for?
Quote
If you're using a custom batch file to compile, you can probably add a delete command in there to get rid of the UDD automatically. Olly apparently doesn't detect when the executable has changed - maybe this should be suggested for OllyDbg 2.0?
I agree. i think i can put together and see if i can shelll it from radasm.
Quote
Cheers,
Zooba :U
Quote from: zooba on January 18, 2008, 01:21:48 AM....since you have some repeated labels in there. That generally suggests that you've debugged the executable before and then changed it.
looks like olly actually put those comments in itself....
Yeah, Olly does a lot of really helpful analysis. That's what makes it one of the best debuggers around (if not the best) :bg
The UDD file is storage. Olly saves its analysis to a UDD file so the next time you debug it the analysis can be loaded. Really big programs can take a long time to analyse, so this saves a lot of time. Of course, if the file changes, Olly doesn't realise this and uses the out-of-date analysis. Deleting the UDD file or using the menus in Olly to remove the analysis will fix it.
Cheers,
Zooba :U
Quote from: zooba on January 18, 2008, 11:05:00 PM
Yeah, Olly does a lot of really helpful analysis. That's what makes it one of the best debuggers around (if not the best) :bg
it would be the best if they did a 64 bit version *hint hint* seriously. it was olly that rekindled my interest in assembly
Quote
The UDD file is storage. Olly saves its analysis to a UDD file so the next time you debug it the analysis can be loaded. Really big programs can take a long time to analyse, so this saves a lot of time. Of course, if the file changes, Olly doesn't realise this and uses the out-of-date analysis. Deleting the UDD file or using the menus in Olly to remove the analysis will fix it.
Cheers,
Zooba :U
it wordks for me. :)
Quote from: evlncrn8 on January 18, 2008, 01:22:22 PM
Quote from: zooba on January 18, 2008, 01:21:48 AM....since you have some repeated labels in there. That generally suggests that you've debugged the executable before and then changed it.
looks like olly actually put those comments in itself....
That's right. my comments aren't nearly as helpful. VBG