Paint crashes when using Brush tool
Pages: 1 2
Chris (121) 472 posts |
I think this is a longstanding bug, but it seems to have got worse for me recently. When using the Brush tool (the one that paints with a sprite), sometimes Paint crashes. It used to give an error message and exit, saving the spritefile in !Scrap, but now it just freezes the computer, requiring a reset. I’m not sure exactly what circumstances cause the crash, but it happens about 50% of the time I try to use the Brush, and takes effect once I click on the OK button in the tool window. I’m using RPCEmu and 5.21 (July), which is otherwise pretty stable for me. As there’s no error message displayed, it’s hard to give any helpful info for a bug ticket. Any advice on how I can get more information on what’s happening? |
Jeffrey Lee (213) 6048 posts |
IIRC when you close RPCEmu it writes the current CPU registers to the log file. If the OS is completely stuck, those registers should hopefully be pointing at the code it’s stuck in, so would be very useful in tracking down the problem. |
Chris (121) 472 posts |
Predictably enough, it was hard to reproduce the error when I wanted to! Used the Brush tool a bit, which after a while prompted this error: Unrecoverable Internal Error (Illegal Window Handle). after which, Paint quit. Ran it again and used the Brush, which produced this error: Internal Error, no stack for trap handler: Internal Error: abort on data transfer at &FAFF3394, pc = FC13FA5C: registers at 201095E0 Closing the error box resulted in more errors, including SWI &205110 not known, and everything got very unstable. I haven’t been able to provoke a full freeze again, but I’ll keep working as I normally do and check the RPCEmu log when one comes along. |
Jeffrey Lee (213) 6048 posts |
A *modules listing or the build date of your ROM would be helpful too, so that we can work out where those addresses are. |
Chris (121) 472 posts |
Here’s the modules output: *modules No. Position Workspace Name 1 FC01ED84 00000000 UtilityModule 2 FC040A80 20000014 Podule 3 FC042A00 200006F4 FileSwitch 4 FC04FA78 20001BB4 ResourceFS 5 FC050760 20001BF4 TerritoryManager 6 FC052C7C 00000000 Messages 7 FC102E18 20001CF4 MessageTrans 8 FC104208 20003AB4 UK 9 FC105E08 20004234 WindowManager 10 FC121458 2010AD54 TaskManager 11 FC1253A8 00000000 Desktop 12 FC126010 00000000 SharedCLibrary 13 FC15A2A4 20009954 VIDC20Video 14 FC15B2F8 200099B4 Mouse 15 FC15B6EC 200099F4 PS2Driver 16 FC15C7DC 00000000 ADFSFiler 17 FC160D4C 00000000 BASIC 18 FC170850 00000000 BASIC64 19 FC17E65C 20009AB4 BASICTrans 20 FC17F434 2000A114 BufferManager 21 FC1806B0 200FADF4 ColourTrans 22 FC1848B8 2000A134 Debugger 23 FC189950 2000A3D4 DeviceFS 24 FC18BE50 20100694 DisplayManager 25 FC18DBA0 2000A514 DMAManager 26 FC190B14 2000A934 DragASprite 27 FC191C8C 00000000 DragAnObject 28 FC1921B8 2000A974 Draw 29 FC1955E0 2000B3B4 FileCore%ADFS FC1955E0 00000000 FileCore%Base 30 FC1A89F4 2000AAB4 ADFS 31 FC1B0CD0 2010D874 Filer 32 FC1B9E18 2005F154 FilerSWIs 33 FC1BA114 2005F254 FSLock 34 FC1BB2BC 2005F5B4 FontManager 35 FC1CB7E4 20060494 FPEmulator 36 FC1D2FE0 200605F4 Free 37 FC1D47DC 20060F54 Hourglass 38 FC1D5258 20061054 IIC 39 FC1D590C 20061094 International 40 FC1DBBEC 200610B4 InternationalKeyboard 41 FC1EEBCC 20061114 InverseTable 42 FC1F5F4C 00000000 NetFiler 43 FC1FA274 20061534 NetStatus 44 FC1FA5D0 00000000 Obey 45 FC1FAF70 20061554 ParallelDeviceDriver 46 FC1FC804 200617F4 Pinboard 47 FC202444 200624D4 PipeFS 48 FC2038E4 00000000 RAMFSFiler 49 FC2047C0 20110B34 ResourceFiler 50 FC204F8C 00000000 ROMFonts 51 FC258FBC 200037D4 RTCAdjust 52 FC2598C8 20003774 ScreenBlanker 53 FC25A230 20062534 ScrSaver 54 FC25AB08 20003714 SerialDeviceDriver 55 FC25BC80 20003674 SerialDeviceSupport 56 FC25C360 20003634 SerialMouse 57 FC25C9E0 00000000 ShellCLI 58 FC25D050 200639B4 SoundDMA 59 FC25ED38 20063AF4 SoundChannels 60 FC2605C0 20065CB4 SoundScheduler 61 FC260EBC 20067CD4 SpriteExtend 62 FC2741A8 00000000 SpriteUtils 63 FC274798 20003554 Squash 64 FC276168 00000000 SuperSample 65 FC276A8C 2006AA74 SystemDevices 66 FC2778C8 200035F4 TaskWindow 67 FC279F88 00000000 WindowUtils 68 FC279FF0 2006ABB4 FilterManager 69 FC27B474 2006AC54 WaveSynth 70 FC27BF60 2006B354 StringLib 71 FC27CA34 2006BB74 Percussion 72 FC27D5F8 2006C494 SharedSound 73 FC27F244 00000000 Filer_Action 74 FC286524 2006D534 DOSFS 75 FC2920B0 2006E8B4 ColourPicker 76 FC29FF28 20074714 ScreenModes 77 FC2A20E4 20075994 DrawFile 78 FC2A7B1C 200775B4 BootCommands 79 FC2AA350 00000000 AUNMsgs 80 FC2B1AF8 20063954 MbufManager 81 FC2B4354 200C1C34 Internet 82 FC2D7420 200C5F54 Resolver 83 FC2F6E48 200C9174 MimeMap 84 FC2F8064 200CA554 LanManFS 85 FC30D348 200D54B4 DHCP 86 FC3120DC 20109454 !Edit 87 FC314BC0 00000000 !Draw 88 FC33E88C 00000000 !Paint 89 FC354DB8 00000000 !Alarm 90 FC362288 00000000 !Chars 91 FC363204 00000000 !Help 92 FC365A7C 200D69D4 TinyStubs 93 FC3675B4 200D7D34 Toolbox 94 FC36C13C 200D9174 Window 95 FC37A404 200DACB4 ToolAction 96 FC37BB14 200DBE14 Menu 97 FC37FBB0 200DD2F4 Iconbar 98 FC382564 200DE7B4 ColourDbox 99 FC385424 200DFB94 ColourMenu 100 FC388118 200E1214 DCS 101 FC38A4A8 200E2614 FileInfo 102 FC38CFDC 200E3B14 FontDbox 103 FC390D6C 200E5154 FontMenu 104 FC393660 200E6634 PrintDbox 105 FC397368 200E7B54 ProgInfo 106 FC39A490 200E9074 SaveAs 107 FC39DDE8 200EA6D4 Scale 108 FC3A03E4 200EBA94 TextGadgets 109 FC3AA1C4 200ED5F4 CDFSDriver 110 FC3AB6B0 00000000 CDFSSoftATAPI 111 FC3AD1E8 200EE234 CDFS 112 FC3B1208 00000000 CDFSFiler 113 FC3B3E6C 00000101 UnSqueezeAIF 114 200F9994 00000000 RPCEmuHostFS 115 200F9D34 200FA134 RPCEmuHostFSFiler 116 20102B54 201052D4 EtherRPCEm 117 201385B4 20138854 StrongTask The build date from the Switcher is 09-July-13. |
Chris Gransden (337) 1207 posts |
I just tried the latest !Paint 2.15 and the most recent OMAP4 ROM. I just get an abort. Takes a while for it to happen. *where |
nemo (145) 2546 posts |
That’s one of the oldest bugs in RISC OS. I remember it happening in RO2 days. |
Chris Hall (132) 3554 posts |
That’s one of the oldest bugs in RISC OS. I remember it happening in RO2 days. Is it being kept for nostalgic reasons or is the fix an extremely difficult one? |
Andy S (2979) 504 posts |
I just tried the latest !Paint 2.15 and the most recent OMAP4 ROM. Although I’ve had a few different exceptions whilst using the brush, I don’t think I’ve had one at an address in SharedCLibrary. I tried to work out what code is at the above address last year. I needed to find what version of the SharedCLibrary (CLib) module was current on Aug 21, 2013. I’m still not sure if it’s version 5-75 or 5-77. Possibly this may have it in the HardDisc4 image: https://web.archive.org/web/20130729053646/http://www.riscosopen.org/content/downloads/other-zipfiles I downloaded that from July 2013 and have copied CLib. It says SharedCLibrary 5.77 (24 Mar 2013). In that CLib I downloaded, the line at offset &000021A8 is surrounded by undefined instructions so I’m not sure code is even supposed to be there! So at this point I don’t know if I’m looking at a different version of CLib to what Chris Grandsen was running or if an error elsewhere caused a branch to the wrong address (in which case I wouldn’t have enough information to track that down). I also tried RMLoading the above version of SharedCLibrary and using the brush tool a lot, but I couldn’t reproduce the crash. |
Andy S (2979) 504 posts |
Please, if anyone else is still getting exceptions when using the brush, post them here with the address and ideally the output of:
Thanks. |
Rick Murray (539) 13840 posts |
Maybe it’s relocation stuff? Load the module, rip it from memory using Zap/StrongEd, and see if what’s there is any different. |
Andy S (2979) 504 posts |
rip it from memory using Zap/StrongEd I didn’t know StrongEd could do that. I only really use it as a hex editor for files on disc. I just downloaded StrongHelp and had a look at StrongEd’s help, and I still don’t know how to do that. How do I do that Rick? I used to have a tool called RMSave that could save a Module to a file, but I assumed that would just be structured the same as any original module file. I don’t really know anything about the internals of modules yet. I assumed the relocation stuff just meant the base address could change, so I thought if I read the base address of the module with “*modules” and then added &000021A8 to that, that “*memoryi” on the result would give me the right line of code. |
Rick Murray (539) 13840 posts |
No idea. But I’ve yet to see a feature of Zap that Fred doesn’t come along and say “StrongEd does that too”. Sorry it isn’t helpful, all my kit is currently turned off because of the weather conditions. I’ve been marathoning The Witcher, which means standing outside in the rain at the edge of the field (good 4G) to download the episodes two by two.
I may be wrong, but I think C modules are a little more complicated. I have certainly encountered branches that went to gibberish places, which made sense after the module was actually loaded. |
Fred Graute (114) 645 posts |
:-)) Yes, StrongED can grab applications & modules from memory too but the feature is a bit hidden in pre-4.70 versions. Click with the right mouse button on StrongED’s iconbar icon to open the Modes menu. In that menu choose the Dump mode. This will open a dialogue box that allows you to grab various bits of memory. In StrongED 4.70 it’s been added to the iconbar menu to make it easier to find: |
Andy S (2979) 504 posts |
That worked great, thanks Fred! |
Andy S (2979) 504 posts |
Offset +&21A8 comes to address 20243BDC in the below routine in the SharedCLibrary (still assuming I grabbed the same version of CLib that Chris had):
The trouble is, there’s nothing obvious in that to identify what that routine is. No SWI calls, and I can’t find one routine in the sources that obviously uses most of those constants in the same sort of place. The -540 near the start seems to be defined as SL_Lib_Offset in RISC_OSLib/s/h_stack so I can only guess this is some sort of memory management code for the stack for C functions. I would have thought the instruction at the actual address where the abort happened should be pretty innocuous, “20243BDC BHI &20243C2C”, just a conditional branch to another line within the same routine. |
Sprow (202) 1158 posts |
The clues are there, they’re just hidden! Look at 20243B30 : E3A02006 : . ã : MOV R2,#6which is _swix(OS_UpCall, _IN(0)|_IN(1), 6). Once you know that you’ll find the macro |
Andy S (2979) 504 posts |
Wow, OK. I did look at |
Andy S (2979) 504 posts |
I think that means it crashed in malloc(). If it was actually a bug in malloc() I think we’d have bigger problems than occasional crashes in Paint. There aren’t many places that Paint itself calls malloc(). With brush selection it gets used to build a palette and hold translation tables. Of course it could also be a RISC_OSLib function that called it or the WIMP. |
Jeffrey Lee (213) 6048 posts |
You also need to bear in mind that softloadable copies of modules typically won’t be binary identical to ROM versions. There are lots of ways in which the two can differ (different code generation from the compiler/assembler due to different CPU type targets, dynamic registration of files with ResourceFS, different versions of the C library stubs for ROM vs. softload, etc.) So although the softload version places the crash site in malloc, in reality it may have been in one of the functions near malloc in the binary. |
Andy S (2979) 504 posts |
Ideally I’d need a dump of SharedCLibrary from that version of the OMAP4 ROM then. I haven’t got an OMAP. Given no-one else has reported a crash near that address, with the possible exception of nemo remembering it, I wonder if it’s a bit of a wild goose chase. I certainly have no record of personally seeing Paint crash in SharedCLibrary. When it happened to Chris near the top of this thread, it looks like that address may have been past the end of the module and it happened when he tried to run Paint a second time after it already crashed. Has anyone had Paint crash more recently whilst using the brush? Unless someone posts details of a new crash we might have to consider the possibility that this particular issue has gone away. |
Andy S (2979) 504 posts |
Please has anyone still got a copy of OMAP4Dev.5.21.zip from around August 2013? Chris Gransden perhaps? The file isn’t on archive.org. I’m hoping I can use something like ROMUnjoin to pull the image apart and extract the SharedCLibrary to find the exact location of the crash. |
Chris Gransden (337) 1207 posts |
There’s one here from 4th August 2013. |
Andy S (2979) 504 posts |
Thank you. *ROMUnjoin happily spat out all the modules from that OMAP4 ROM image and StrongEd found me offset &21A8 in that SharedCLibrary. Funnily enough, it’s just a little further down in that same function,
I’m not really sure what to make of this. |
Rick Murray (539) 13840 posts |
First, it’s probably the LDR two instructions earlier that is choking – perhaps knowing the values of the registers may help? Secondly, it helps to not look for exact code matches, but to look for “something similar”. I started with the AND #&80000000 followed by an AND �. Don’t pay any mind to the actual registers, they may differ depending upon the whims of the compiler. I found it looking in the prebuilt library that is linked into my ROM. So working backwards, I examined all the object files and found it again in “o.alloc”. The registers differed, but the code “pattern” was the same. Since I don’t have a damned clue how to mess around with the shared MakeFiles to get the compiler to spit assembly (parameter -S), I yanked it out, fired up CC, and built it manually. By inserting a dummy printf() statement, and tracing it’s location in the output (isn’t debugging on RISC OS great?) I came up with this: This is where the problem is:
Which corresponds to this bit of source:
The CMP with zero is checking if the block is NULL.
What we can see here is we’re loading something from a fixed location. My money is on GUARDCONSTANT. If I follow that, does it equal &3E694C3C? Yes. So now we know we’re using the guarded blocks version. The next line, then, will be indirecting to try to find that guard word. We already loaded block for the non-NULL test, so that LDR will be going to find the ->guard part. As I’m working my way through this, I’m wondering if there might be a case of something corrupting one of your memory claims? Or possibly using a bogus (but non-NULL) reference? Do you have any backtrace, to know where in Paint it is failing? (more specifically than “the brush tool”)? Do you have the value of any registers at the point of failure? If it helps, I created a simple backtrace handler that dumps its output to file or screen (depending if file handle given). It’s a modified, tidied, and fixed ☺ version of the one in a later incarnation of DeskLib. |
Pages: 1 2