Programming Forums > Application Development > Assembly

omega_red · Jun 24th, 2005, 6:21 AM

I was playing with some of my ever-unfinished code and found that it crashes for no apparent reason in about 10% of runs. After some investigations I found that rep movsb can be dangerous

(Toggle Plain Text)

format PE CONSOLE
entry start

include '%fasminc%\win32a.inc'

;------------------------------------------------
use = ExitProcess
section '' code data readable writeable executable
;------------------------------------------------
start:

	mov		ecx, 0x90909090	; nops
	mov		[a_1], ecx
	mov		[a_1+4], ecx
	mov		[a_1+8], ecx
	mov		[a_1+12], ecx
	mov		ecx, (data_end-data_start)
	mov		esi, data_start
	mov		edi, a_1
	rep		movsb

;	nop								; uncomment this to prevent crashes

a_1:
	times 0x10	db	0xcc			; fake int3, will be replaced by NOPs
	nop
	ret

;------------------------------------------------

data_start:
;	nop
	jmp		$+2
;	nop
	jmp		$+2
data_end:

;------------------------------------------------

align 4
data import

library kernel,'kernel32.dll'

import kernel,\
	ExitProcess,'ExitProcess'

end data

(FASM format, win32)

This innocent piece of code can crash randomly. Why? It's easy to see if we have JIT debugger assigned and analyze program's state upon crash:

(Toggle Plain Text)

00401031   0090 90909090    ADD BYTE PTR DS:[EAX+90909090],DL
00401037   90               NOP
00401038   90               NOP
00401039   90               NOP

As can be seen, EIP "slipped" by 1 byte, hence the error.

Interestings things pop up while we are debugging this. Tracing by "step into" and "step over" gives different results. "Step over" on REP = program exits, code is incorrect:

(Toggle Plain Text)

0040102C  |. F3:A4          REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[>
0040102E  |. 90             NOP
0040102F  |. 00EB           ADD BL,CH
00401031  |. 0090 90909090  ADD BYTE PTR DS:[EAX+90909090],DL
00401037  |. 90             NOP
00401038  |. 90             NOP

And with "step into" all is OK.
I observed those effects only with movsb - ...w and ...d seem to not behave like this ("step over" on movsw causes program halt too, but code is copied OK).

And for last, something that made me really confused - EXE in CONSOLE format crashes (EIP "slip") much more often than the GUI one.

My CPU: Intel P4 3.2 HT (enabled). OS: Win XP SP2.

Link for compiled exe: http://212.33.90.248/~omega/p.exe

I have made some more tests. It seems that this code crashes only on P4 CPUs

Quote:

[OK]
# Celeron 2.40
Max CPUID: 5
Vendor ID: GenuineIntel
Version: 00000f34
(type 0, family 15, model 3, stepping 4)
Features: bfebfbff (ebx=00010800, ecx=00017437)

# Celeron 2.0
Max CPUID: 2
Vendor ID: GenuineIntel
Version: 00000f29
(type 0, family 15, model 2, stepping 9)
Features: bfebfbff (ebx=0001080a, ecx=00017408)

# Celeron 1.8
Max CPUID: 2
Vendor ID: GenuineIntel
Version: 00000f13
(type 0, family 15, model 1, stepping 3)
Features: 3febfbff (ebx=0001080a, ecx=00000000)

# Sempron
Max CPUID: 1
Vendor ID: AuthenticAMD
Version: 00000fc0
(type 0, family 15, model 12, stepping 0)
Features: 078bfbff (ebx=00000800, ecx=00000000)

[Crash]
# P4 3.2 HT enabled
Max CPUID: 5
Vendor ID: GenuineIntel
Version: 00000f34
(type 0, family 15, model 3, stepping 4)
Features: bfebfbff (ebx=00020800, ecx=00017437

# P4 3.0
Max CPUID: 5
Vendor ID: GenuineIntel
Version: 00000f33
(type 0, family 15, model 3, stepping 3)
Features: bfebfbff (ebx=00020800, ecx=00001053)

# P4 3.0 HT enabled
Max CPUID: 3
Vendor ID: GenuineIntel
Version: 00000f41
(type 0, family 15, model 4, stepping 1)
Features: bfebfbff (ebx=00020800, ecx=00017437)

Thread Tools
Show Printable Version Email this Page
Display Modes
Switch to Linear Mode Switch to Hybrid Mode Threaded Mode

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > Assembly

Fun with MOVSB and prefetch