SEGF in gst_initialize

Trying to figure out why something doesn't work and for this I did gdb
on the code. I then noticed a SEGF trigged only inside GDB. Tracing it
down I ended up at the gst initialization code somehow causing a SEGF.
The code is the following:

gst_initialize( NULL, NULL, GST_NO_TTY );

Calling this line causes SEGF only in gdb. Anything wrong here? I used
NULL for image and kernel string since in the doc there has been no
indication at all what has to go there if anything at all.

--
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.ch/ ,
http://www.moddb.com/games/4057/epsylon )
- Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
http://www.moddb.com/engines/9/dragengine )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/31/2009 10:19 PM, Roland Plüss wrote:
NULL is fine.

However gst traps SEGVs for its own generational GC.  You can use
"handle SIGSEGV noprint" at the beginning of your gdb session, or place
it in .gdbinit.

Real SEGVs become SIGABRT.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

the first place? It's just that when my apps cause a SEGF at any place
red flags come up immediatly.

( Side note, smalltalk is now running *thumbsup* using my special hack
to link it into a pure c++ environment )

--
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.ch/ ,
http://www.moddb.com/games/4057/epsylon )
- Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
http://www.moddb.com/engines/9/dragengine )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 11/01/2009 12:09 AM, Roland Plüss wrote:
> I can understand that but is it not bad to begin with to cause a SEGF in
> the first place? It's just that when my apps cause a SEGF at any place
> red flags come up immediatly.

If you are asking the OS to report writes into the "old generation" by
write-protecting pages, the OS has no way to do so but raising a SIGSEGV
(or similar exception under Mac OS/Mach and Windows).

Again, that's not a real problem.  When a SIGSEGV is really an error and
is turned into a SIGABRT, the backtrace is totally recognizable and you
get the fault address in the backtrace.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

not supposed to be allowed to write. There are situations where it is
needed like in console emulation where you work with funky hardware but
is this really required for a scripting/programming language? I'm rather
astonished smalltalk uses SEGFs for control flow. I thought with that
simple and clear design such tricks are not required. Looks though like
I'm wrong there.

--
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.ch/ ,
http://www.moddb.com/games/4057/epsylon )
- Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
http://www.moddb.com/engines/9/dragengine )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 11/01/2009 02:43 AM, Roland Plüss wrote:
> There are situations where it is
> needed like in console emulation where you work with funky hardware but
> is this really required for a scripting/programming language? I'm rather
> astonished smalltalk uses SEGFs for control flow. I thought with that
> simple and clear design such tricks are not required.

It's not control flow.  It's used by GC.  It's not needed---it's just
one implementation of a write barrier.  It's not needed either for
"funky hardware", though I know that some emulators track dirty
rectangles using the same technique.

Signals (except for SIGKILL and SIGSTOP) are there to be trapped
whenever useful.

Configure with --disable-generational-gc (and enjoy the speed loss...)
if you feel uncomfortable.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk