Applesoft is usually fairly well-behaved. For instance, this will give an OUT OF MEMORY error:
10 GOSUB 20
20 GOTO 10
However, there are many Applesoft bugs, mostly benign. Wikipedia mentions a couple that "crash":
- A deficiency in Applesoft's error-trapping with ONERR means that the system stack would not be reset if an error-handling routine did not invoke RESUME, potentially leading to a crash.
- Due to a short-cut in the programming of the overflow test when evaluating 16 bit numbers, entering any number from 437760 to 440319 for a new line number at the BASIC prompt will cause Applesoft to crash, usually to a monitor prompt.
E.g. for the second one you can just type the following and press return:
Crash behaviour is unpredictable because (a) as you say, there is no memory protection - if the CPU starts executing arbitrary memory locations then "anything" can happen, and (b) I/O is memory-mapped - even just reading memory can cause problems. The following will usually hang the machine:
PRINT PEEK(49280) : REM $C080 SWITCHES OUT ROM/SWITCHES IN LC BANK 2 RAM
Uninitialized RAM will be a mix of #$00 and #$FF. If the CPU executes #$00 (i.e. BRK) the break vector($FFFE/$FFFF) might point to $0000, which could be anything - leading to another BRK etc.
On a NMOS 6502 (not 65C02) various opcodes actually hang the CPU:
POKE 768,2: CALL 768: REM EXECUTE HLT OPCODE
If you want to see what a BRK crash looks like:
POKE 768,0: CALL 768: REM EXECUTE BRK OPCODE
It will print the BRK address + 2, A/X/Y registers, P status register, and stack pointer. E.g:
0302- A=03 X=9D Y=00 P=36 S=F2