olly treating functions as data.

[darrenls59]

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

[zooba]

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

[darrenls59]

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

Code Select Expand


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

Code Select Expand


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

[Tight_Coder_Ex]

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

[zooba]

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

[darrenls59]

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.

[darrenls59]

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

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?

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.

Cheers,

Zooba :U

[evlncrn8]

....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....

[zooba]

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

[darrenls59]

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

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. :)

[darrenls59]

....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