Puzzling visits of the Guru with Cubic IDE, vbcc 0.8, on ACA1230

[tygre]

Hi all!

I am facing a puzzling (and frustrating! ) problem while developing with Cubic IDE, vbcc 0.8 on an Amiga 1200. I used to have a Blizzard 1240 and my code would compile and run fine (see AmiModRadio).

Then, I had to replace (temporarily!) my 1240 with an ACA1230 and, boom , the same code, compiled the same way, crashes at random places when run... with a variety of Gurus (8000 0004, 8000 0003, 0100 0003...)

As far as I understand, my makefile and options do not precise any processor... so what could happen?

(AmiModRadio uses Miami and MUI, which both run fine with the ACA1230.)

Any help/suggestion are welcome before I
Thanks!

[phx]

Are you sure your development environment didn't change? Or did you work on the source in the meantime?

Do you still have old object files compiled with the B1240? I would try to isolate the problem by comparing them with the new objects.

Best would be to generate assembler output with both cards (-S option) and compare the sources.

[tygre]

Thanks PHX!

Yes, I am sure that I did not change my code before starting to receive these random visits... Also, they are quite random, pointing at various locations in my code as far as I understand...

Yes, I have back-up'ed the object files although I am not sure their dates and I did not use the -S option.

What could I do to understand (and fix!) these visits?

[phx]

Currently I have no idea what could be causing your problems, except a hardware problem or software mis-configuration of your ACA1230. But then you would probably see strange effects in other areas of the system as well.

Did you already try different optimization levels? With optimizations enabled vbcc may use a lot of memory. Maybe this involves (defective) RAM-regions which are otherwise not touched by most programs.

When you still have a backuped B1240-compiled object file from a source text, which was not modified since then, so compare it with the new object. Either by using a simple "cmp"-tool (Aminet) or by reassembling (ReSource, IRA, ADis, etc.) the objects and comparing the reassembled source (with a diff-like tool).

[tygre]

Hi PHX!

Some good news and some questions...

The good news is that, after putting back my Blizzard 1240, my code compiles and runs as expected (and when it crashes, it is consistent, I can find why, and I can fix it ), hoorey!

The questions is: what could be different between having the Blizzard 1240 and the ACA1230 that the same program would run fine with the former and crash randomly with the latter?

I have checked that I using the "standard" math library from my original Workbench 3.1 disk, same for RexxMast, same for MUI... Yet, sometimes the Gurus talks about FPU...

Any ideas?

PS. You can find the makefile here and the options here...

[zero]

MOD playback code uses interrupts and the FPU perhaps?

[tygre]

Hi Zero!

It should not because I am actually using AREXX to use an existing player, for example HippoPlayer, which works fine independently of AmiModRadio...

Puzzling, eh

[phx]

What are you doing with the FPU in your program?

In fact, the 68882 FPU is different to the internal 68040 FPU. Maybe you compiled for 68040-FPU and/or linked with m040.lib? I have no experience with CubicIDE, and I haven't seen any options in your Makefile or project.options file which specify CPU type or math libraries.

So in case you didn't specify any -fpu=68882 or -fpu=68040 option, then the compiler will generate code to use the AmigaOS mathieee-libraries. This also includes the mathieeesingbas.library, which has some known bugs under OS3.1 with 68040 and 68060 FPUs.

I probably don't have to mention that vbcc 0.8 may be 10 years old (depending on the version used in CubicIDE). Which doesn't mean that it doesn't work, but there were quite a lot of bug fixes since then.

[tygre]

Hi PHX!

Actually, I don't do any FPU-related computations... all the more puzzling! Could there be a way to inspect the object files or executable to identify possible illegal calls?

I like Cubic IDE and vbcc but I am opened to alternatives? Could you suggest me any?

Cheers!

[phx]

Originally Posted by tygre

Could there be a way to inspect the object files or executable to identify possible illegal calls?

You can reassemble or disassemble them.

When running MungWall and Enforcer (or MuForce from the MuTools) you can identify the crash location or any illegal access. It will show you the offset into a section, which you could possibly translate into a source name and line number with a FindHit-like tool, provided that you compiled the program with LINE-debug hunks (vbcc -hunkdebug option, or just -g in newer 0.9 versions). Or look for the offset in your reassembled source.

But first of all you should make sure that the program and object files generated by the compiler on an ACA1230 are the same as on a B1260. Did you already confirm that? It didn't became clear in your last postings.

I like Cubic IDE and vbcc but I am opened to alternatives? Could you suggest me any?

The latest vbcc 0.9e is here: http://sun.hasenbraten.de/vbcc/
But I don't know if you can simply update it inside Cubic IDE. You may have to switch to a command-line approach and write a Makefile yourself.

[tolkien]

I used to use cubic ide with VBCC and I updated VBCC by simply replacing files.

[matthey]

Originally Posted by tygre

I like Cubic IDE and vbcc but I am opened to alternatives? Could you suggest me any?

I doubt the problem is vbcc. Consider checking your memory, checking for viruses and removing hacks and patches temporarily. If upgrading vbcc to the newest version, it is going to be easier than installing GCC.

Originally Posted by phx

You can reassemble or disassemble them.

When running MungWall and Enforcer (or MuForce from the MuTools) you can identify the crash location or any illegal access. It will show you the offset into a section, which you could possibly translate into a source name and line number with a FindHit-like tool, provided that you compiled the program with LINE-debug hunks (vbcc -hunkdebug option, or just -g in newer 0.9 versions). Or look for the offset in your reassembled source.

Why not link to your FindHunkOffset?

http://sun.hasenbraten.de/~frank/pro...HunkOffset.lha

It works here and is more reliable across compiler versions than GCCFindHit. Why Amiga 68k installations do not have it installed in the bin directory I do not know.

Originally Posted by phx

But first of all you should make sure that the program and object files generated by the compiler on an ACA1230 are the same as on a B1260. Did you already confirm that? It didn't became clear in your last postings.

Good advice.

[tygre]

Dear Phx, Tolkien, and Matthey!

Thank you for all your kind advices!

I will make the time during the week-end to follow them and will keep you posted... Beware that I am still learning so I may bother you with silly/newbie questions about disassembling and hunks and offsets...

Talk to you soon!

[tygre]

Dear all!

So, I finally took the time to debug this problem and, beside a few bugs in my code that were easy to fix, the main problem was the stack!?

Just by setting the stack to 32768 (instead of the default 4096), AmiModRadio works well

I looked around but could not find code to check and increase the stack size, would you have any pointers to share about checking/increasing the stack programmatically in C?

Cheers!

[matthey]

Originally Posted by tygre

So, I finally took the time to debug this problem and, beside a few bugs in my code that were easy to fix, the main problem was the stack!?

Just by setting the stack to 32768 (instead of the default 4096), AmiModRadio works well

Simple but deadly mistake. I increase the stack size for my shells which helps when running more modern shell launched programs.

Originally Posted by tygre

I looked around but could not find code to check and increase the stack size, would you have any pointers to share about checking/increasing the stack programmatically in C?

Read The Manual (RTM) section 12.4.3.

http://server.owl.de/~frank/vbcc/docs/vbcc.pdf

It should be easy to increase the stack size as described with "size_t __stack=32768;". Unless you have a program which uses more stack size when processing more data, it is best to avoid the -stack-check option. Scout will show the amount of stack used by tasks.

[tygre]

Hi Matthey!

Originally Posted by matthey

Read The Manual (RTM) section 12.4.3.

http://server.owl.de/~frank/vbcc/docs/vbcc.pdf

It should be easy to increase the stack size as described with "size_t __stack=32768;". Unless you have a program which uses more stack size when processing more data, it is best to avoid the -stack-check option. Scout will show the amount of stack used by tasks.

Ah, thank you so much, indeed I should RTFM

Cheers!

PS. Could a kind moderator mark this thread as "solved"?