ReSource crashing

[Leffmann]

I'm running ReSource on an A1200 with KS 3.1 and BetterWB 3.2, and it keeps crashing on me.

Usually it happens when I use shift+cursor keys to fine-step through code, or otherwise move through it and see alternating "???" and garbled code. ReSource stops responding to keyboard input, the menu items disappear, and it just sits there eating 100% CPU time. It happens for files of all sizes, so it's not an out-of-memory problem.

Has anyone experienced this? I've tried disabling all patches and things from my startup-sequence, and I can't figure out whether it's ReSource itself or something else that's causing it.

[copse]

Never experienced it. Maybe debug it and break into it when it does this and see if there's some loop which it is stuck in.

[copse]

I'd suggest you use my disassembler PeaSauce, but unfortunately it's still not production ready.

[emufan]

i suggest starting completely w/o startup-sequence and compare behaviour. i think it just needs ENV: and maybe resource:
one more thing, it does ask here every time i start it, for screen type, it will open on.
with those RTG ( uaegfx ) screen i'm not happy with ( performance wise or the like ) - best is hires pal/ntsc w/o lace.
crashes i've never seen, i have to say.

[musashi5150]

Have you tried the -s option to force system legal rendering? Funnily enough I had to use this option today when I installed ReSource on OS4.1

[dlfrsilver]

ressource is doing that on my 1200 when during disassembling, i'm going thru a data part of the current program i'm processing. When turned to what it is really, the problem disappears.

[Codetapper]

I've also had this problem before, I think it does actually fix itself eventually but it can often take so long I give up. I have learnt to save often.

Usually it happens when you Shift-UpArrow into unknown code and who knows what it's doing, but it must be trying to work out references or data type and takes forever.

[mark_k]

It might be trying to find the next instruction boundary. For example if you have a couple of hundred KB of data which is shown as code, but it's not set to any specific data type, ReSource might be working through disassembling all that data to find the next instruction boundary when you page-up. Or maybe it's scanning back in the disassembly to find the nearest data type change, and if that's a long way away it takes a while.

That issue wouldn't happen as much if you set the data type for various routines in that chunk of data beforehand. Then (for example) ReSource might only be working through a few KB when you page-up. (I think the key combination to set code is left Amiga-C? Also if you press F6 (that's from memory, might be wrong) when at a reference like JSR START+$123456, ReSource will automatically create a label at offset $123456 and set the data type there to code. So as you proceed with disassembling a program the size of unknown chunks decreases.

I did notice that earlier versions of ReSource (up to V5) seem to be much faster than V6. Something to do with text rendering probably.

[Leffmann]

Thanks guys, I've looked some more at it and concluded it's definitely a problem with ReSource:

Open load-file, select version.library from Workbench 3.1, move to the absolute end of the file, click Options 1, check Multiple Constants and select Assembler: Assem, and close the options window. ReSource will now lock up. I can reproduce this on a fresh Workbench 3.1 and ReSource 6.06 install.

I've found another case where it seemingly is working outside of the file, and is probably stuck disassembling the entire RAM, or something.

I agree with what Mark says, and I think the best thing is to immediately determine the data type for the very beginning and a few more points down the file before doing anything else.

Thanks

[matthey]

Originally Posted by mark_k

That issue wouldn't happen as much if you set the data type for various routines in that chunk of data beforehand. Then (for example) ReSource might only be working through a few KB when you page-up. (I think the key combination to set code is left Amiga-C? Also if you press F6 (that's from memory, might be wrong) when at a reference like JSR START+$123456, ReSource will automatically create a label at offset $123456 and set the data type there to code. So as you proceed with disassembling a program the size of unknown chunks decreases.

Part of the problem is that Resource is not very smart about automatically identifying code, data, strings, etc. The new version of ADis does a much better job automatically saving a lot of time.

http://www.heywheel.com/matthey/Amiga/ADis.lha

Too bad it doesn't have an editor like Resource as all the flags for data types are in memory and can be changed. Also, it's really geared more for system compliant Amiga executables than hardware banging games so far.

P.S. Denis Ahrens has updated his tiny D68k disassembler for the 1st time in many years. The new version 2.1.0 fixes a problem with MULS.L/MULU.L and some 68020+ addressing modes. The new version is on his web site:

http://denisy.dyndns.org/d68k/

[denis2342]

Originally Posted by matthey

Part of the problem is that Resource is not very smart about automatically identifying code, data, strings, etc. The new version of ADis does a much better job automatically saving a lot of time.

http://www.heywheel.com/matthey/Amiga/ADis.lha

Too bad it doesn't have an editor like Resource as all the flags for data types are in memory and can be changed. Also, it's really geared more for system compliant Amiga executables than hardware banging games so far.

P.S. Denis Ahrens has updated his tiny D68k disassembler for the 1st time in many years. The new version 2.1.0 fixes a problem with MULS.L/MULU.L and some 68020+ addressing modes. The new version is on his web site:

http://denisy.dyndns.org/d68k/

I don't use dyndns anymore. The latest D68k (2.1.3, 15.1.2023) is appended as attachment.

[Jope]

I zoned it for the ages.