aout still segfaults after modprobe binfmt_aout on Slackware 14.0_x32
 

I've been using 32-bit slackware 12.1 (2.6.24.5 kernel),
under which the following has been working fine.
But now it immediately segfaults under a clean full install
of 32-bit slackware 14.0 (3.2.29 kernel).

What I'm trying to run is the old crisp2.2e editor,
available at, e.g.,
http://ibiblio.org/pub/Linux/apps/editors/terminal/
The -bin.tar.gz stuff has been running fine under
slack 12.1 as long as
modprobe binfmt_aout
is uncommented in /etc/rc.d/rc.modules
But now the same procedure under slack 14.0x32 immediately
segfaults (and the -src.tar.gz stuff no longer compiles).
Any clue why the binary segfaults under 14.0x32? Thanks,
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

a a.out is normally used as an intermediary temp
you then "link" a few a.out" type files into one *.so ( think windows dll )

And normally you do not use an a.out for a program ( you can - but not normally )

so you updated and the old program using old and different libs is seg faulting

rebuild it on the new system
BUT
from ibiblio
1994 !!!
that might be a 16 bit program

new os's might not run it

download the src version and build the source after you install gcc 1 ( maybe gcc 2.4 might work )

looking at the Makefile
it is for DOS and OS/2

i would not even try to hack this old code
but if you want go for it

a.out is a binary format used by Linux back in the 90's and was replaced by elf.

Just because gcc spits out a.out named files does not make them a.out in format this is just a throwback on gcc's part and only occurs when you do not specify the output file name.

Oh dear, Linux has always been 32 bit moving on towards 64 bit.

The code is actually multiplatform and covers DOS/Win and several UNIX variants including Linux and BSD.

However the code has been stale for over 15 years and the lack of standards back then means that it would take a lot of tweaking to get it to compile again (and I did have a good look)

Thanks, guys. Yeah, the old source is definitely no longer compilable. But let me repeat that the binaries in that -bin.tar.gz download do run perfectly under slackware 12.1 and 12.2.

In addition to uncommenting modprobe binfmt_aout, I should also mention that I have a collection of several very old libs that are needed by these old binaries, and that I copy to /lib/. And then everything "just works" under 12.1 and 12.2.

So suggestions like 16-bit can't be relevant since the binaries run. My question isn't why the binaries don't run, but why they run under 12.x and segfault under 14.0. What's changed from 12.x to 14.0 that might account for that different behavior? Thanks again,
John

forkosh in my attempts to get the code to compile I have noticed that several syscalls/library calls have changed, you can run strace to see where exactly they break but I doubt thee is anything you can do.

As for the fresh compile, I have a 64 bit copy of cm, cr & ninfo so far, if you need them in 32 bit I can fire up a VM and spit them out.

You will have to test them out for functionality though as I have no idea how to use them, they do execute and give out basic info though.

Thanks, ww. The 64-bit stuff would be fine. Even better, though, your sources (presumably modified) and makefile (or makefile-like info). If you've got a working set of sources, I'll be happy to make a neat tarball and put it up on the net. And I'll try to get the X-version, xcr, working, too. I failed to get any of that stuff working myself, and would be very interested to see what you've done. Just email me an attachment zip/tarball/whatever at john@forkosh.com (and maybe include your name so I can credit you in a README). Thanks.

strace -f cr (or xcr, for that matter) on the existing binaries just gives me
execve("/usr/local/bin/cr", ["cr"], [/* 43 vars */]) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
Not very helpful.

Since the 12.x /lib's obviously work with the existing binaries, I tried combining them with 14.0 (warning: these commands hang the system if not done more carefully than I've summarized them below),
cp -a /lib /lib-combined
mv /lib /lib-14.0
cp -a mount-point-for-12.2/lib /lib
mv /lib /lib-12.2
ln -s /lib-combined /lib
and then I tried various experiments in /lib-combined, using the 12.2 stuff with the 14.0 stuff. Nothing worked (and it sometimes hung). I'm pretty much at a dead end trying to get it working on 14.

Have you tried

This is a work in progress but should build the previously mentioned parts before it bombs out.

http://wildwizard.abnormalpenguin.co...isp2.2f.tar.xz

Have tried it now. But no change, exactly identical segfault behavior. But thanks for the suggestion, Petri.

Thanks so much, again, ww. That's certainly a >>lot<< of work you put into it. I untarred your tarball and left everything, including your machine.h and s-machine, unchanged. Just typed make on both 14.0x32 and 14.0x64 (dual booting) installs. Both built cr,cm,ninfo like you said, but cr still segfaults on both. But strace produces way more output, too much to put here -- output from strace cr 2> crtracexx (where xx=32,64) is at http://www.forkosh.com/crtrace32 and http://www.forkosh.com/crtrace64, both segfaulting at the same place after issuing an fcntl(). Just to double-check: I read your previous post as saying cr works for you when you compile it. Is that right? If so, any idea what I might be doing wrong here?

I haven't studied your work beyond this point yet, but the fact that you got it to compile (which I never did) suggests it can eventually be made to work, hopefully with finite effort. So I'll definitely be putting some renewed effort into that, too (after first diffing your -2f sources against Fox's original -2e sources to see how you got it compiling).

Any further effort you want to contribute also greatly, greatly appreciated. I'm amazed how much effort you already did put in, especially since you remarked that you don't use crisp. At the risk of "looking a gift-horse/wizard in the mouth", how come so much time into a tool you're not using? Thanks yet again,
John

Curiosity in code rot was the main thing.

As for cr running I was looking at the help output, it seems to be failing somewhere in its main start up routine however I can't pin it down.

My curiosity got the better of me so I decided to work out what happened to crisp in the long term and it seems to have gone commercial.

http://www.linuxjournal.com/article/2829

I also checked out his site and the price tag is 100 UK pounds which is pretty exy for a text editor, though it would depend on how much of the feature set you need.

I use jed as an editor and it provides plenty of syntex highlighting and some extra feature like highlighting the opening brace/bracket when you close them as well as auto indents. Trying the trial version of the crisp editor it highlights the opening one as soon as you place the cursor after an existing closing one so that sort of extra, extra feature might be handy.

Yeah, I was aware it had gone commercial. But there was also an intermediate open source version, which I've placed a copy of for you at http://www.forkosh.com/crisp-2.5.1.tar.gz (in case your curiosity gets the better of you again<grin>). But I can no longer google that version on the web. Its INSTALL file mentions davidn@blaze.net.au, and that blaze.net does ring a bell (I downloaded it on 17 June 2001, so don't explicitly recall much), but I can't seem to conjure up a url there that still gets it. In any case, it doesn't have an X version, which is what I primarily use, so I've continued using the 2.2e binaries which have worked -- till now.

The 100-uk-pounds is indeed a bit much for the commercial version, but I dislike commercial stuff even more for the shenanigans they frequently put you through to control their product. So I just use open source stuff, which is usually as good, if not better, anyway. In this case, my fingers are just so used to crisp/brief, after almost two decades use, that I'd just rather not put my head through the trouble of learning yet another editor. But I suppose it's unavoidable, and now may be that time. It'll probably be emacs, just because that's sufficiently ubiquitous that I trust it'll be around and maintained pretty much forever. By the way, as for the syntax highlighting you mentioned, I personally pretty much hate that. Just makes it harder for me to read what I wrote. But that's just me; everybody has their own equally good personal preferences.

After a bit more fun with it I can give you this :-

http://wildwizard.abnormalpenguin.co...isp2.2g.tar.xz

It needs to be compiled in 32 bit so if your multilib'ing it like me you need to use the 32dev.sh script from Eric (Do read his instructions on how to use it).

It still doesn't work though it does get further then it did before and the whole thing compiles now as well.

Also note that I have changed the layout around a lot and debugging is turning up to the max.

The Makefile doesn't have a complete install routine yet so don't try that without fixing it first.

Thanks, ww. I added a few debugging statements to cr_main.c, macros.c, builtin.c that you can download from http://www.forkosh.com/crdebug.zip which contains those three functions from the src/crisp/ directory. Output is

Crisp> prog_name = "./cr"
Crisp> entering init_playback()
Crisp> returned from init_path(&bhelp)
Crisp> returned from setup_env()
Crisp> returned from init_register()
Crisp> returned from sym_init()
Crisp> entering startupfile()
Crisp> entered startupfile()
Crisp> entering str_exec("crisp")
Crisp> entered str_exec("crisp")
Crisp> entering nexecute_macro(lp)
Crisp> entered str_exec("_init")
Crisp> entering nexecute_macro(lp)
CHK_ALLOC: Freeing non-alloced memory.
A program error (segmentation error) occured during startup.

which is where I'm at so far. Now need some debug stuff in nexecute_macro() to trace it further. But that may turn out to be a pretty straightforward bug, not X-window library related like I had originally guessed. If it is straightforward, ought to be easy to trace and fix -- it certainly can't run, and I don't think it can hide for long, either.

Meanwhile, I did download the trial commercial version. Kind of like the old "slickedit" editor complaints -- too many darn bells and whistles.

No need for those debugging statements when you run it in gdb with full debugging enabled in the compile you get to see all of that anyway. when it bombs out you type in backtrace and it gives you the chain of functions and where they are in each source file.

gdb also lets you see the pointer addresses which is how I picked up on the code not been 64bit compliant, if your keen it's in word.c

I also had a quick look at the current version just to have a quick look and just the download size gives away the complexity of where it has gone since the early 90's