Search crashes on AmigaOS 4

[josefwegner]

Hi,

TuneFinder 1.2 crashes when clicking on "Search". The older versions worked fine under OS4.

Maybe this information from GrimReaper helps:

Crash log for task "TuneFinder"
Generated by GrimReaper 53.19
Crash occured in module kernel at address 0x01806304
Type of crash: unknown exception
Alert number: 0x01000009

Register dump:
GPR (General Purpose Registers):
   0: 0183872C 596A7970 00000002 0180631C 6052FE30 0235BDDC 0235BDCC 0235BE3C
   8: 69224620 00000000 0000000A 01839BF8 39933953 0000000D 596AC004 021FA968
  16: 59698004 596ABFFC 165AB001 6EAB1170 8000000C 00010000 8000000B 8000000A
  24: 80000008 FFD60001 596A7970 00000001 6052FE30 0235ECC2 6052FE30 021FA968


FPR (Floating Point Registers, NaN = Not a Number):
   0:     -4.4678e+307         -1.63122         0.799349              0.5
   4:      4.76837e-07       4.5036e+15       4.5036e+15       4.5036e+15
   8:              661       4.5036e+15              255       4.5036e+15
  12:     -4.4678e+307         0.166667     6.86455e-144      5.06982e+58
  16:     9.88992e+299     -9.86252e+43          4.42458          9.53257
  20:      4.41275e-06     4.31408e+167    -1.73446e+131      3.67986e+44
  24:     1.68722e-257     1.14901e-144    -3.29678e+272    -5.82453e+202
  28:      3.69052e+89    -7.83231e-306     1.67869e-201     1.93175e-208

FPSCR (Floating Point Status and Control Register): 0x82004000


SPRs (Special Purpose Registers):
           Machine State (msr) : 0x0002B030
                Condition (cr) : 0x59819DC0
      Instruction Pointer (ip) : 0x01806304
       Xtended Exception (xer) : 0x018407B0
                   Count (ctr) : 0x00000000
                     Link (lr) : 0x00000000
            DSI Status (dsisr) : 0x01860BA0
            Data Address (dar) : 0x00000000



680x0 emulated registers:
DATA: 00000000 00000003 597289E4 00000000 00000000 00000001 597289E4 606B90E4
ADDR: 59718000 597289E0 59718000 00000BE6 6180FB96 596A7D48 0235ECC2 596A79D0
FPU0:                0                0                0                0
FPU4:                0                0                0                0



Symbol info:
Instruction pointer 0x01806304 belongs to module "kernel" (HUNK/Kickstart)

Stack trace:
    native kernel module kernel+0x00006304
    native kernel module kernel+0x00038734
    native kernel module kernel+0x00020094

PPC disassembly:
 018062fc: 6063631c   ori               r3,r3,25372
 01806300: 44000002   sc
*01806304: 4e800020   blr
 01806308: 7c641b78   mr                r4,r3
 0180630c: 3c600180   lis               r3,384

[sandlbn]

It could happen when memory is allocated. Could you check if this version is working under OS4? TuneFinderOS4

[josefwegner]

Hi Sandlbn,

Thank you for the quick reply. Yes, that new version no longer crashes in OS4.

[sandlbn]

So, here is the full version that will work for OS4 and should be for OS3 without debug window, but because you have to allocate more than 8MB for some search results under OS3, search results will fail when there are many results. I have to think about how to make it compatible with the 68k subsystem in OS4. TuneFinderOS4

[josefwegner]

Thanks again for the new version.

What call exactly is crashing? I could check on my X5000 how to make the call work.

[sandlbn]

What call exactly is crashing

You can check here: main...OS4 But it is GetOptimalBufferSize

[josefwegner]

I do not think that allocating the memory is the issue. I could create a 128MB buffer (malloc(32 * 1024 * 1024 * sizeof(int))) without any issue. I compiled the test program with vc +aos68k. I suspect the poking of the memory headers might the issue. I will create a test program with your GetOptimalBufferSize method and see where exactly the root cause is.

[sandlbn]

Maybe allocating that much is unnecessary; I just tested with the initial allocation at 2MB and can search all the stations. It could be that the best is to leave as it looks like optimal value 2 * 1024 * 1024;

[sandlbn]

I just tested it under AOS 3.1, 3.9, and 4.1. My assumption was wrong, as the buffer in the download code can grow up to 64MB.

[josefwegner]

Thanks for reverting the change. I checked your GetOptimalBufferSize method. Peeking the memory headers on Amiga OS4 will result in an available memory size of 0 and largest size of 0. This means that the function will calculate a buffer size of 0. Allocating zero amount of memory most likely triggers the crash.

You removed the function completely, still I wanted to ask why you peeked the memory headers instead using:

available = AvailMem(MEMF_ANY);
largest = AvailMem(MEMF_ANY|MEMF_LARGEST);

[sandlbn]

You removed the function completely, still I wanted to ask why you peeked the memory headers instead using:

It is a temporary fix since I have to rewrite and test it properly. AvailMem(MEMF_ANY) will only be used to verify if the network response buffer won't exceed available memory, since it's growing over time. If memory can't be allocated, the request will fail and go to the cleanup.

[sandlbn]

Memory allocation improved in #36

[sandlbn]

@samo790 @josefwegner Can you test the new memory allocation for the HTTP calls on AOS 4.1? https://drive.google.com/file/d/12jb8GdBhwL8zbGPu3dlkv51s49ixbMeY/view?usp=sharing

[josefwegner]

Hallo @sandlbn,
Thank you for your new version. I experienced no crashes so far. Loading 100 station worked without any issue.

[samo790]

Seems working so far :-)

[josefwegner]

Sorry, I had a DSI today.

First, I was searching for radio stations in Japan (JP and MP3), and randomly selected three and played them. Then I was searching for Power Metal filtering by Germany and MP3.
After clicking on "Abspielen" I got a DSI:
Crashlog_TuneFinder_2024-12-11_07-59-31.txt