Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

68K Beta bug prpblem reports

tomsmart1
2013-10-12
2013-10-24
1 2 > >> (Page 1 of 2)
  • tomsmart1
    tomsmart1
    2013-10-12

    Sorry for start this new Topic because i can't create Tickets.

    I test the 68k version build 2013 10 11 on a A2000 with 68060 82 MB Ram, OS 3.9 CGX and P96 with Mulib and Mutools, Muforce and MuGuardinAngel active.

    1. Crash of the read.module no hits over serial or sashimi, only the window is shown and then it crash the complete system after a while screen goes black. IF i replace it with the orginal read.module from DOPUS V5.82 it works.

    2. APP Icons shows only on DOpus Screen not on WB screen if you don't use DOpus as WB replacement and start DOPUS5 form the workbench and use its on screen.

     
  • xenic
    xenic
    2013-10-15

    @tomsmatr1

    1. The OS3 read module works fine under emulation on OS4. Debugging it for a "real" classic Amiga would require "real" Amiga hardware and I don't think any of the dopus5 developers use a classic Amiga. Unless kas1e can recruit an OS3 programmer who uses a classic Amiga, I don't think anything can be done about your problem. Dopus5 program, library and modules are about 1674048 bytes total. That comes close to maxing out an unexpanded classic system, so maybe your problem is a memory issue. If that's not the issue then I can't tell what might be going wrong just from examining the read module source code.

    2. That's a problem on OS4 and possibly all the Amiga platforms. For that reason and several others, I still use Dopus4 for daily use and only run dopus5 for testing. It sucks when you have iconified several programs, close dopus5 and discover that you have no icons to reopen iconified programs :-(

     
  • kas1e
    kas1e
    2013-10-16

    @Xenic

    The OS3 read module works fine under emulation on OS4. Debugging it for a "real" classic Amiga would require "real" Amiga hardware

    At some point i may just create ready-to-use EUAE package where we can test os3 version. There is some other problems with it (as i remember, join.module crashes on os3 too), but we can worry about after all current problems will be sorted.

    It sucks when you have iconified several programs, close dopus5 and discover that you have no icons to reopen iconified programs :-(

    That can be fixed later as well, just not everything at one time :) currently there is still problem with that correct exit and removing of patches ..

     
  • tomsmart1
    tomsmart1
    2013-10-16

    @xenic

    1. it is good to know that the os3 read.module work on your os4. I have 1MB Chip and 82MB Fast Ram so i got no problem for that side ;)
      I hat a closer look today and find out if i disabled my ENV:DOpus/Text Viewer settings by renaming, i get it most time to work and display the select text file. If it crashes now i get this output over serial SAD!SAD!SAD!SAD!SAD!SAD!SAD!SAD!SAD!SAD!.
      By testing the setting of the read.module i find out the font settings are the problem, after selecting a font with the asl font requester the readmodule crashes and i get the debug message to.
      Can you or kas1e please test it with OS4 if you find the time with OS3 and OS4 version of the read.module.

    2. So if it the same with OS4 that the patchcode for the Workbench functions are not 100% correct and something like a register got changed during the patchcode.
      I test it with the orginal 5.82 under OS3.9 and there are the icons displayed on both screen WB and DO5 ones. It is no showstopper so it can be fixed later.

     
  • xenic
    xenic
    2013-10-17

    @kas1e

    That can be fixed later as well, just not everything at one time :) currently there is still problem with that correct exit and removing of patches ..

    We covered that problem several months ago. I explained that the cleanup and removal of patches won't happen until the library open count reaches 0 (zero). Back then I fixed the modules to close the dopus5.library when they close and got the dopus5.library open count down to 2. I spent days trying to determine why the open count wasn't going to 0 but had no success. I tried again all day today and still can't figure out what is keeping the library count from going to 0 when the dopus5 program shuts down. You will need to find someone smarter than me to track down the problem.

     
  • kas1e
    kas1e
    2013-10-17

    @Tom
    We currently overblown by everything else, so for time being let's skip those 68k tests. Once we will fix bugs which cleary there, then i can setup euae with all necessary stuff and then we can do some tests/fixes with 68k. I have already in mind some 68k problems, but just currently its the problems which we can skip, till we not done with other bugs which we see even in ng versions.

    @xenic
    Yep, i remember that problems about count 0.. Will try to debug it as well in next days.. Dunno what hold the counter too ..

     
  • xenic
    xenic
    2013-10-17

    @kas1e
    If you are going to use debug output, I should warn you that the latest OS4 updates using AmiUpdate have broken the debug output if you are using "DumpDebugBuffer" to see the debug output. Getting the debug output with "DumpDebugBuffer" after first turning on your OS4 computer will work. If you do an AmigaOS reboot (Ctrl-Amiga+Amiga) then DumpDebugBuffer will show no new debug output.

    You can test it with attached test utility (debug) like this:

    Turn on your OS4 computer and enter "DumpDebugBuffer CLEAR" in a shell to dump the debug output from the initial boot.

    Using my attached "debug" utility, enter "debug" in a shell. Then enter "DumpDebugBuffer CLEAR" in a shell and you will see a line of debug output from my test utility. Every time you enter "debug" and then enter "DumpDebugBuffer CLEAR" you will see the line of debug output.

    Reboot your OS4 computer and enter "debug" in a shell. Then enter "DumpDebugBuffer" in a shell and you will see nothing printed. No matter how many times you enter "debug", DumpDebugBuffer will show nothing.

    Here is my test utility that just prints one line to debug output using OS4 "DebugPrintF":>

     
    Attachments
  • xenic
    xenic
    2013-10-17

    @Tom
    I tested changing the font in the text reader in the OS4 version and it crashes when I load a new font. Hopefully kas1e will test it too and add a ticket for the that crash. When they fix the OS4 debug output, I'll take a look at the problem.

     
  • kas1e
    kas1e
    2013-10-17

    @Xenic

    Tested your debug.lha's outputs on serial: it always works as expected, i.e. if i soft reboot, or hard reboot, i always have "Debug output test!!" in my serial console.

    Then i tested memory output by setting by setting my os4_commandline variable back from serial to memory, and when i boot first time and run your debug binary, and then dumpdebugbuffer, then it works. Then i do soft-reboot, again run your debug binary, and type dumpdebugbuffer : and there is again all works.

    Then just in case, i tested with soft-reboot + run debug binary + dumpdebugbuffer clear => all works as expected.

    I.e. all seems works as expected. I am on debug kernel all the time (if that can make difference anyway ..). Strange ! Maybe something was with HW when you do tests ? Or sams's related only .. We can ask on forum for sam owners to try to reproduce it..

    As for read.module crash when we just choice a font: yes, i am able to reproduce it, and stack trace point out on read.c:3911 read_pick_font() function. I made a ticket for #22

     
    Last edit: kas1e 2013-10-17
  • xenic
    xenic
    2013-10-17

    @kas1e
    I don't use the debug kernal so the problem might be in the normal kernal. I don't usually need debug output from the OS so I've always used the normal kernal. That way I just got the debug output from a test program. I'll try the debug kernal to see if it makes any difference. What os4_commandline variable are you using to switch from memory to serial??

     
  • kas1e
    kas1e
    2013-10-17

    @xenic

    What os4_commandline variable are you using to switch from memory to serial??

    Check plz http://www.os4coding.net/blog/kas1e/advanced-serial-debugging-guide

    part 5.1. called "Firmware method".

    I show there examples for sams, a1, peg2, etc. But to note "munge" will works only on debug kernel (which we all should use anyway all the time :) it catch bugs better than normal one). If you just need memory then for sam's should be something like this in the boot-environment of SAM:

    setenv os4_commandline "memory"
    saveenv
    
     
  • xenic
    xenic
    2013-10-17

    @kas1e
    I've discovered why the library open count doesn't go to zero. The open count is kept in the library base. The code in Library/launcher.c is accessing the library base and changing the library count. That's a real hack. Programs aren't supposed to mess with the contents of library bases.

    The bottom line is that the code in launcher.c creates a library cleanup paradox. The cleanup which shuts down the launcher can't occur until the library open count is 0, but the library open count won't got to 0 until the launcher shuts down. I have no idea how to fix a paradox like that.

    EDIT: I just tested the SASC compiled version of dopus5. It appears to have the same problem. When you quit SASC dopus5 the library count for dopus5.library is 12. After you close all the modules with "expunge all" the dopus5.library count is 2, just like our OS4 GCC dopus5. Also, if you look in Ranger/DOS/Processes you will see DO_LAUNCHER under ramlib just like in the GCC version. That means that SASC version wasn't cleaning up after itself when you quit either.

    The only reason we notice the difference is because GCC dopus5 isn't putting appicons on WorkBench like SASC version when not running dopus5 as WorkBench replacement.

     
    Last edit: xenic 2013-10-17
  • kas1e
    kas1e
    2013-10-18

    @xenic
    So its legacy bug in original code. They imho just forget to test it all in last versions. And i assume they all wasn't care much in those days about "if our patches removes or not", because no one complain.. Its maybe works for them in some previous versions, then they start to works futher, do some strange hack in launcher.c and after that removing of patches stop working.

    In other words, it seems we need to deal with launcher.c code and somehow rewrote that part with hack ?

     
  • xenic
    xenic
    2013-10-18

    @kas1e

    In other words, it seems we need to deal with launcher.c code and somehow rewrote that part with hack ?

    No. What I call a hack is necessary to keep Dopus5 from crashing. The point I'm trying to make is that the library count isn't staying above 0 because a program has opened the library and not closed it, it's because the library must wait for all child processes to exit. In wb.c and launcher.c the library opencount is increased and decreased to indicate whether it's safe for the library to close and cleanup. In wb.c there is this code:

        // Bump library open count so we won't get expunged
        ++wb_data->dopus_base->ml_Lib.lib_OpenCnt;
    

    As you can see, preventing the library from cleaning up is intentional. I don't really understand all the IPC launching code and am not going to try to change it. Changing the IPC launching code without understanding exactly how it works could just make things worse.

    EDIT: I see now that the library counter altering in wb.c and launcher.c are there because the actual library closing in SASC is done in a link module which could not be accessed from the library code. Changing the open counter from wb.c & launcher.c was the only way to keep the library from cleaning up until all child processes have terminated, so it's not really a "hack". No matter how the child processes are tracked, the library can't be closed and cleaned up untill all child processes are terminated.

     
    Last edit: xenic 2013-10-19
  • tomsmart1
    tomsmart1
    2013-10-20

    @xenic and kas1e

    I test for the library open count problem here with the original and the beta from 2013 10 20 and i use Scout to view the open cont.

    I found out like you if i start DOpus5 the open count goes up to 2 for both. If i then close Dopus5 the open count (all windows and Screen are closed) the open count is still up to 2. But if i wait about 5 to 10 sec the open count goes to 0, with the original version it's happen earlier.
    With the beta i saw one time that then open count goes up to 1 and back to 0 again in 3 seconds and than stays at 0.

    If i then flush the libraries the beta freez the hole system no debug output over serial. The original flushs without a problem.

     
  • tomsmart1
    tomsmart1
    2013-10-20

    1. DoWBStartup in the directory WBStartup are "ELF" file in the OS3 archive is this correct and needed?
     
  • kas1e
    kas1e
    2013-10-20

    @tom
    nope, its for os4 only, need to delete from all others

     
  • xenic
    xenic
    2013-10-20

    @Tom

    Thank you for fixing the openfont bug in read module, it work on OS3 and the Prefs are now work too.
    Have still the problem that the read.module crashes with no debug output most with small text file like ENV:AISS. It opens the window an show the text and after some seconds the mouse freez ...

    I can't reproduce your crash on my OS4/PPC computer. I can read files that only have 4 cahracters with no problem. As I've mentioned before, I don't think any of the Dopus5 developers is using a classic Amiga and there isn't much we can do if the problem doesn't occur when running the OS3 version under emulation. Since you're talking to us on the developer forum, I assume that you are a programmer. Is there any reason why you can't compile the read.module and do some debugging yourself?

     
    • tomsmart1
      tomsmart1
      2013-10-21

      I can't reproduce your crash on my OS4/PPC computer. I can read files that only have 4 cahracters with no problem.

      I do a little more testing and find out hat the reasion is not the lengh of the file. The crash happend reproduceable every time if i press the right mousebutton if the mousepointer is in the read.module Window (text area) not on the windowborders. Sorry i over seen it the last times i test it.

      As I've mentioned before, I don't think any of the Dopus5 developers is using a classic Amiga and there isn't much we can do if the problem doesn't occur when running the OS3 version under emulation.

      This is Ok and i know it that not always the emu works like the Classic Hardware and it is a hard way to find bug that you can't reproduce. My motivation is to find bugs, like the openfont one that was cross plattforms. If you can't reproduce it i so i have to do more and deeper testing to track it down maybe we use different settings and so on.

      Is there any reason why you can't compile the read.module and do some debugging yourself?

      My C skills are only very very basic.

       
  • xenic
    xenic
    2013-10-20

    @Tom

    I test for the library open count problem here with the original and the beta from 2013 10 20 and i use Scout to view the open cont.

    In the original Dopus5, the library code is linked with a SASC supplied object file that takes care of the required library functions (init, open, close, expunge etc.) and therefore works differently than our GCC compiled library.

    In your original post you said:

    APP Icons shows only on DOpus Screen not on WB screen if you don't use DOpus as WB replacement and start DOPUS5 form the workbench and use its on screen.

    I assume that by "APP icons" you mean the icons that are shown when you iconify a program. When I run our OS3 version of Dopus5 under emulation on OS4 (not as WB replacement), the icons appear on the WorkBench screen and not on the Dopus5 screen. Are you sure that our OS3 Dopus5 (GCC compiled) is placing the icons on the Dopus5 screen instead of WorkBench? Unfortunately, our OS4 Dopus5 doesn't display the icons anywhere; the programs are just gone.

    In your original

     
    • tomsmart1
      tomsmart1
      2013-10-21

      In the original Dopus5, the library code is linked with a SASC supplied object file that takes care of the required library functions (init, open, close, expunge etc.) and therefore works differently than our GCC compiled library.

      I know it, i want to show that on OS3 the openconts of the library goes to 0 after i close DOpus5 complete because you all wrote that on your tests the count goes not to 0 and stays at 2.

      I assume that by "APP icons" you mean the icons that are shown when you iconify a program.

      Yes

      When I run our OS3 version of Dopus5 under emulation on OS4 (not as WB replacement), the icons appear on the WorkBench screen and not on the Dopus5 screen. Are you sure that our OS3 Dopus5 (GCC compiled) is placing the icons on the Dopus5 screen instead of WorkBench?

      Yes, i test it again if in the settings at "WB Emulation" "Display AppIcons" is activated.

      Unfortunately, our OS4 Dopus5 doesn't display the icons anywhere; the programs are just gone.

      I have this to with the Beta if "Display AppIcons" is not activated.

       
  • kas1e
    kas1e
    2013-10-21

    @Tom
    If you not programmer yourself, you can try to recruit someone from 68k camp who can specializes on working on 68k related moments. There is really not many to do to make it all good for os3, just few fixes there and there and it will works on 3.0 and uppear without problems. Just show to persons you will find in interest that: https://sourceforge.net/p/dopus5allamigas/wiki/If%20you%20want%20to%20join%20to%20project/

    And if he will ok, just contact us. We can explain him everything and he can jump on board pretty fast.

    @xenic
    I see you keep fixing tickets, that pretty cool ! I am sure you know it, but those ones which is os4 related and which (imho) can be fixed more or less easy: 8, 10, 11, 13 and 19.

    For myself i think i will try now to get rid fully of putreg/getreg at all from code too (as for us its just dummy now), so code also will looks cleaner. I also will reduce a bit HookData structure in the string_hook.h, by removing those a4 and a6 ulongs entries. So, everything will be clean. Of course will test everything before, and for beginning will just comment it out.

    Then after we will test it for few days and all going well, want to remove all SAVEDS stuff as we for sure not need it anymore, and it can make only sense for 68k when some special mode in gcc uses which we didn't and will not use. Code will be cleaner, everything will be better.

    Then, i want to try to somehow clean all our mess in terms of "double-structures" , when we for example have one in include/libraries/dopus5.h which uses by library, and the same copy of structure in some another include in main program. I.e. to avoid mess with which Simon meet when he works on it : he change one structure in hope its only in one place, but it also dupes in the includes. While we need to clean that, and only make it all be one time.

     
    Last edit: kas1e 2013-10-21
  • kas1e
    kas1e
    2013-10-21

    @Tom

    I think that i don't find one.

    Why didn't try ? Try to ask on EAB, maybe you will find someone who will join to us.

    I think that 99% of the problems/Bugs are cross plattform and not OS3 specific.

    No. Some are. There already few which os3 only, like for example to make it works on os3.0, need to do some workarounds for varargs based function, as well as some other os3 specific only parts. As well as need to deal with version of rexxsyslib.library, which prevent dopus5 from running on os3.0, but only on os3.9. And that crash on which you point out now in the os3 version of read module when you press RMB on the text area didn't happens on os4 for example. So also specific to os3. Maybe some settings of WB prevent it from crash through .. But i am on debug kernel with munge and memguard and there is nothing happens when i press by RMB over text area.

    If you are not interested in tests with OS3 so ignore my reports/posts and remove the OS3_beta form the server.

    What i saying is that we have no developers there who have classic amiga. So even if we all want to have os3 version be good (the same as morphos), then, we didn't have now no os3 developer, no morphos developer. If you can help us to find ones, that can help a lot. That the point. We can worry about os3 and morphos of course, but without having actual hardware and developers from, there can't be done much, only few bits. Later, we of course can build some euae version and do some tests on it, but better (and its much better) to have developer there who will carry about os3 support, and will test/fix bugs related to it. That why we need help to find out os3 developer.

    edit: blah deleted accidentally previous post from tom, but message is understandable from my answers i assume.

     
    Last edit: kas1e 2013-10-21
  • xenic
    xenic
    2013-10-21

    @Tom

    I do a little more testing and find out hat the reasion is not the lengh of the file. The crash happend reproduceable every time if i press the right mousebutton if the mousepointer is in the read.module Window (text area) not on the windowborders. Sorry i over seen it the last times i test it.

    That problem I can reproduce. I'll take a look when I get a chance.

     
1 2 > >> (Page 1 of 2)