BTW, I am running slackware 14.1 32-bit. So it's likely how you are compiling or other things influencing the segmentation fault. I'm not running a stock kernel here, so I'm not sure if there is some kind of kernel protection in play either. I do think the program is at fault here, and haven't taken the steps to run valgrind or other kinds of memory debugging to see if there is a corruption going on.

I also tried compiling 0.11, and I got syntax errors. Not a good sign.

Tell the program devs about it, if you don't know the program internals it's hard for you to fix the bug.

I set SLKCFLAGS="-g -O0 -fPIC" (which the SlackBuild uses to set CFLAGS and CXXFLAGS) which made blassic much more verbose about its breakdown.

This is a session running blassic alone.
and this is a session using valgrind:
Near as I can tell, an uninitialized pointer is the culprit but I'm not sure what to do about it.

you can try to set a breakpoint and go into it - or try to link statically...

I already have a breakpoint right where I need it (at the point of segfault) and more information than I can process so far.

Even if static linking masked the problem for blassic, it doesn't help me in the long run. I have a lot of packages with segfaulting problems (even the esteemed Alien's vlc). In fact, it's almost a coin toss whether a package I install will actually run or scream "segfault" and die. There can't be that many poorly put together packages. There must be a problem with my Slackware setup which is why I must continue along this path.

That said, I find it amazing that a simple basic interpreter would need over 40 source files each thousands of lines long and during execution would have to link up with over 15 dynamic libraries. And in spite of the code verbosity, it can't handle a simple heap violation.

Well, that's a different problem, and this path is not necessarily the best path for that problem.

If you have lots of segfaults, there are probably several different causes. There certainly are a *lot* of poorly put together packages. In the case of vlc, it isn't fair for me to imply it might be poorly put together: no, it's a major achivement that it works at all, considering that it has to rely on so many poorly put together dependencies and rotten APIs.

But whilst the in-depth approach you've taken with blassic is good for finding problems in blassic, it's not really the best way of finding and solving a more general problem. For one thing, don't start with blassic: C is much simpler to debug than C++. For another, you only need to find out whether the stack dumps of the various failing programs have a common theme (what were they trying to do when they crashed). And most of all, it's just easier to manage your Slackware installation properly. No little experiments outside a VM, no mix-and-match between -stable and -current, the absolute minimum of multilib, and, dare I say, no rebuilds of standard packages with debugging symbols outside a VM. I apologise if you haven't done anything like that. But it will be more effective to eliminate this potential problem by performing an audit of your system against a Slackware install dvd.

The reason for this is that incompatibilities in dynamic linked libraries will often cause segfaults. You can make this happen by using a different .so file to the one that the program was built against. This is why the often-repeated advice to "just create the missing symlink" is *TERRIBLE* advice. As a different example, the gdal library can optionally be built with a patched internal version of libjpeg to support 12-bit jpegs -- this mostly works, but it makes qgis (which depends on gdal) segfault in one or two very specific places.

Or it might be hardware...

That's just glibc trying to helpful. As far as I know, you can ignore everything after the line "invalid pointer" part; we already have a backtrace with line numbers, and we're not going to learn much from the memory map.

This is a bug though probably harmless. You can fix it by adding sigfillset(&act.sa_mask); before the call to sigaction.


So apparently arrayvarstring["a$"].value is uninitialized. It looks like all Array<C> constructors do initialize it, so I'm not sure how that could be. Is it possible some versions of C++ runtime libraries don't like the 0 length array (new C [0])? It is legal C++ though.

You probably want to break a little earlier: in every Array<C> constructor step through to check whether value gets initialized.

It was mentioned the crashes happen on at least 2 boxes, so it's pretty unlikely to be hardware.

I can assure you that mine is a vanilla Slackware installation (with multilib).

I can't guarantee that some obscure package I installed hasn't slipped in a rogue substitute library somewhere but md5ing all of my libraries will take some time. Of course, this is rendered unlikely since both 32-bit and 64-bit compilations of blassic have the same segfault problem - meaning that both 64-bit library and its equivalent 32-bit library would have had to be changed the same way.

If it helps, some of the segfaulting packages (like vlc) still run under gdb. In fact, the run instruction for my vlc is echo run | gdb vlc.

Slightly off-topic, but just in case you aren't aware:

If you experience segfaulting packages that run fine for others you should check that your hardware is fine by running memtest86+ for an extended period. This is simply one of the first thing to do if strange segfaults and/or compilation-errors pop up on a system. If your system doesn't run this test without errors you are sure to have a hardware problem. The slackware install DVD has the memtest option available when you boot from it.

btw) Keep in mind that completing the memtest run without errors doesn't actually guarantee that the hardware is fine. I've seen memory errors pop up only when a system is pushed harder, ie during compilation when the voltage lines might drop.

Blassic throws exactly the same problems when I run it outside of X. This is definitely no memory glitch.

It is taking me longer than expected to learn how to set a break point at line 401 in var.cpp (either in gdb, valgrind or both) so if it takes me a while before I can provide more info don't think I have given up on this task.

I'm thinking blassic is no longer maintained. Their main site is down and distros ship with patched versions in order for it to even build. How about FreeBasic or some other FLOSS basic compiler or interpreter ?

I only keep blassic around for those rare occasions when I get a little maudlin since it is closest to the basics I grew up with (like Commodore 64 basic or GWbasic). For any remotely serious programming, I would of course use Java, C or C++ (or even fpc).

As explained before, my main reason for trying to fix this is to gain some experience at fixing other rogue programs (although admittedly, vlc with all its dependencies might be beyond my abilities). Since blassic used to work before the latest Slackware upgrade, it is possible that one or more libraries doesn't operate the same way that blassic expects it to anymore. If I give up now, I will never know.

Check out the patches that the other distros push, maybe they found the bug. You could also try upgrading Slackware package-wise and try to isolate the package change that caused it.

Has anyone else been able to reproduce your issue? the3dfxdude in post #2 can't reproduce and I just built blassic 0.10.2 from SBo on both
Slackware 14.1 x86 and x86_64 and can't reproduce either.

Before we go around calling blassic and vlc rogue, let's make sure the problem isn't something particular to your configuration. You're not
being very precise in your reports. What Slackware version are you using? When you say "the latest Slackware upgrade", which do mean?

--mancha

As my profile shows, I am running Slackware 14.0 (I chickened out of upgrading to 14.1) and I have installed the blassic-0.10.2 package which I got from SlackBuilds.org (blassic 0.11 was never finished to a stable version).

Although my Slackware installation is pretty much vanilla, I suspect a problem with how it is setup but so far I have no way of knowing whether the problem is with my Slackware setup or with blassic itself. All I know is that when I built the package under Slackware 13.37 there were apparently no problems (even when running the package under 14.0) but after compiling under Slackware 14.0 I get segfaults.