fbc segmentation violation

General FreeBASIC programming questions.
Post Reply
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

fbc segmentation violation

Post by VANYA »

Hi!

Looks like I found a compiler error on win32, dos systems.

here's an example (I've cut out all the redundancy to make it easier to identify the error):

Code: Select all

const m_pi=3.14159265358979323846

type sine_wave_generator
        declare sub set_cycle(cycle as single)
        declare sub add_modulation(x as long)
        declare function get_next() as longint
        declare function get_next(modulation as long) as longint

        position as unsigned long
        _step as unsigned long
end type

enum ADSR
	ATTACK
	ATTACK_RELEASE
	DECAY
	DECAY_RELEASE
	SUSTAIN
	RELEASE
	SOUNDOFF
	FINISHED 
end enum

type envelope_generator
        declare sub set_rate(rate as single)
        declare sub set_hold(value as single)
        declare sub set_freeze(value as single)
        declare sub key_off()
        declare sub sound_off()
        declare function get_next() as longint

        state as ADSR
        AR as longint
        DR as longint
        SR as longint
        RR as longint
        TL as longint
        fAR as unsigned long
        fDR as unsigned long
        fSR as unsigned long
        fRR as unsigned long
        fSL as unsigned long
        fTL as unsigned long
        _fOR as unsigned long
        fSS as unsigned long
        fDRR as unsigned long
        fDSS as unsigned long
        current as unsigned long
        rate as single
        hold as single
        freeze as single
        declare sub update_parameters()
end type

type fm_operator
        declare sub set_freq_rate(freq as single, rate as single)
        declare function get_next() as longint
        declare function get_next(modulate as longint) as longint
        declare function get_next(lfo as longint, modulate as longint) as longint

        swg as sine_wave_generator 
        eg as envelope_generator
        ML as single
        DT as single
        ams_factor as long
        ams_bias as long
end type

function fm_operator.get_next(ams as longint, modulate as longint) as longint
        return (cast(long,swg.get_next(modulate)) * eg.get_next() shr 15) * (ams * ams_factor + ams_bias) shr 15
end function
Please confirm or deny this. Is there really a bug?

I get:
Aborting due to runtime error 12 ("segmentation violation" signal)
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbc segmentation violation

Post by fxm »

Yes, compiler aborting, but just with 'gas'.
Can you test with 'gcc' ?

Are you sure you are using the correct operator precedence ('shr' vs '*') ?
Each 'shr 15' applies on each full expression at their left !
(close to 'shr 30' in total !)
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: fbc segmentation violation

Post by SARG »

in type sine_wave_generator declare function get_next(modulation as long) as longint, modulation is LONG
but in
function fm_operator.get_next(ams as longint, modulate as longint) as longint
return (cast(long,swg.get_next(modulate)) * eg.get_next() shr 15) *

parameter is LONGINT and swg is dimmed as sine_wave_generator

I hardly understand the code maybe it doesn't mater.

In 64bit
D:\fbdebugger\fbdebugger-New\test5.o:fake:(.text+0x2e): undefined reference to `SINE_WAVE_GENERATOR::GET_NEXT(int)'
D:\fbdebugger\fbdebugger-New\test5.o:fake:(.text+0x48): undefined reference to `ENVELOPE_GENERATOR::GET_NEXT()'
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: fbc segmentation violation

Post by VANYA »

Can you test with 'gcc' ?
There is no such error with gcc.
Are you sure you are using the correct operator precedence ('shr' vs '*') ?
Each 'shr 15' applies on each full expression at their left !
This is not my code, but the code angros47, so I can't say. I tried different options with the Longint type and got this error.

SARG! It does not matter whether the code is competently or incorrectly , the main thing is that the compiler is confused and reports a segmentation error. It shouldn't be, shouldn't it be? Or am I wrong? And yes originally in the code angros47 everywhere there was a type of integer!
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbc segmentation violation

Post by fxm »

VANYA wrote: Oct 19, 2022 12:29 This is not my code, but the code angros47
Yes I see:
viewtopic.php?p=193345#p193345
But it's plausible in 64-bit but not in 32-bit.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: fbc segmentation violation

Post by VANYA »

fxm wrote: Oct 19, 2022 12:48
VANYA wrote: Oct 19, 2022 12:29 This is not my code, but the code angros47
Yes I see:
viewtopic.php?p=193345#p193345
But it's plausible in 64-bit but not in 32-bit.
@fxm
I randomly tried to get a workable version. As a result, I found an error not in the angros47 program, but in the compiler :)
Just when I do not know where the error is, I begin to frantically change everything in a row and sometimes by a random method it turns out, as in the case of: viewtopic.php?p=295288#p295288
fxm
Moderator
Posts: 12081
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbc segmentation violation

Post by fxm »

I never said there is no compiler bug (at least for 'gas').
To me there is both a compiler bug and a code line with the 2 'shr 15' which looks quite dodgy.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: fbc segmentation violation

Post by VANYA »

fxm wrote: Oct 19, 2022 14:12 I never said there is no compiler bug (at least for 'gas').
To me there is both a compiler bug and a code line with the 2 'shr 15' which looks quite dodgy.
fxm , as I wrote, it's not my code and I haven't even thought about the code and don't know if it's right or wrong. Maybe you're right.
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: fbc segmentation violation

Post by SARG »

I reduced the code for an 'easier' finding of the bug and added some changes causing no crash.

Code: Select all

type tt1
        declare function gn() as longint
        ar as longint
end type

type tt2
        declare sub gn()
        eg as tt1
        v1 as long     '<<-- if longint : no crash, only here or only below
end type

sub tt2.gn()
        dim as long vlg '<<-- if longint : no crash
        dim as longint vlgt
        vlgt= (eg.gn() shr 1) * (vlgt * vlg + v1)  '<<-- switching the 2 parts of multiplication : no crash
end sub
SARG
Posts: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

Re: fbc segmentation violation

Post by SARG »

The crash is due to out of bounds in reg.bas/function regAllocate line 279 :

Code: Select all

'' This will regFree() the register
		irStoreVR( this_->vregTB(r), this_->vauxparent(r) )
Using existing asserts gives :
reg.bas(248): assertion failed at REGFINDFAREST: r <> INVALID

The value of r, in line above, is equal to INVALID (-1) causing the crash.

Unfortunately I can't go further as I don't understand what is exactly done in REGFINDFAREST function.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fbc segmentation violation

Post by coderJeff »

I pushed changes to fbc/master that should fix this.

Under the hood, regFindFarest() is called when all the registers are allocated to virtual registers in the current statement/expression and registers need to spill to allow the next emit operation. On gas x86, there's only 6 registers to work with so I'm surprised this bug was never found before now - it's an old one.
VANYA
Posts: 1834
Joined: Oct 24, 2010 15:16
Location: Ярославль
Contact:

Re: fbc segmentation violation

Post by VANYA »

coderJeff wrote: Oct 22, 2022 19:39 I pushed changes to fbc/master that should fix this.

Under the hood, regFindFarest() is called when all the registers are allocated to virtual registers in the current statement/expression and registers need to spill to allow the next emit operation. On gas x86, there's only 6 registers to work with so I'm surprised this bug was never found before now - it's an old one.
Thanks
Post Reply