The ubuntu binary version didn't work for me (immediate crash on startup), so I grabbed the snapshot and built that with –enable-debug –enable-ludicrous-mode, ran it in gdb and got this:

(gdb) run
Starting program: /Programs/schismtracker-src/schism/schismtracker
[Thread debugging using libthread_db enabled]
[New Thread 0xb7a2eb20 (LWP 12291)]
*** stack smashing detected ***: /Programs/schismtracker-src/schism/schismtracker terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7cc4da8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7cc4d60]
/Programs/schismtracker-src/schism/schismtracker[0x8096b56]
/Programs/schismtracker-src/schism/schismtracker[0x808705c]
/Programs/schismtracker-src/schism/schismtracker[0x807c835]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7bdd775]
/Programs/schismtracker-src/schism/schismtracker[0x804c5a1]
======= Memory map: ========
08048000-080fa000 r-xp 00000000 08:01 459313 /Programs/schismtracker-src/schism/schismtracker
080fa000-080fb000 r–p 000b2000 08:01 459313 /Programs/schismtracker-src/schism/schismtracker
080fb000-08109000 rw-p 000b3000 08:01 459313 /Programs/schismtracker-src/schism/schismtracker
08109000-08366000 rw-p 08109000 00:00 0
09b7c000-09b9e000 rw-p 09b7c000 00:00 0 [heap]
b7a06000-b7a30000 rw-p b7a06000 00:00 0
b7a30000-b7a34000 r-xp 00000000 08:01 34363 /usr/lib/libXdmcp.so.6.0.0
b7a34000-b7a35000 rw-p 00003000 08:01 34363 /usr/lib/libXdmcp.so.6.0.0
b7a35000-b7a3c000 r-xp 00000000 08:01 2589944 /lib/tls/i686/cmov/librt-2.9.so
b7a3c000-b7a3d000 r–p 00006000 08:01 2589944 /lib/tls/i686/cmov/librt-2.9.so
b7a3d000-b7a3e000 rw-p 00007000 08:01 2589944 /lib/tls/i686/cmov/librt-2.9.so
b7a3e000-b7a40000 r-xp 00000000 08:01 34352 /usr/lib/libXau.so.6.0.0
b7a40000-b7a41000 r–p 00001000 08:01 34352 /usr/lib/libXau.so.6.0.0
b7a41000-b7a42000 rw-p 00002000 08:01 34352 /usr/lib/libXau.so.6.0.0
b7a42000-b7a5a000 r-xp 00000000 08:01 35320 /usr/lib/libxcb.so.1.1.0
b7a5a000-b7a5b000 r–p 00017000 08:01 35320 /usr/lib/libxcb.so.1.1.0
b7a5b000-b7a5c000 rw-p 00018000 08:01 35320 /usr/lib/libxcb.so.1.1.0
b7a5c000-b7a71000 r-xp 00000000 08:01 2589940 /lib/tls/i686/cmov/libpthread-2.9.so
b7a71000-b7a72000 r–p 00014000 08:01 2589940 /lib/tls/i686/cmov/libpthread-2.9.so
b7a72000-b7a73000 rw-p 00015000 08:01 2589940 /lib/tls/i686/cmov/libpthread-2.9.so
b7a73000-b7a76000 rw-p b7a73000 00:00 0
b7a76000-b7a89000 r-xp 00000000 08:01 34549 /usr/lib/libdirect-1.0.so.0.1.0
b7a89000-b7a8a000 r–p 00012000 08:01 34549 /usr/lib/libdirect-1.0.so.0.1.0
b7a8a000-b7a8b000 rw-p 00013000 08:01 34549 /usr/lib/libdirect-1.0.so.0.1.0
b7a8b000-b7a92000 r-xp 00000000 08:01 34631 /usr/lib/libfusion-1.0.so.0.1.0
b7a92000-b7a93000 r–p 00006000 08:01 34631 /usr/lib/libfusion-1.0.so.0.1.0
b7a93000-b7a94000 rw-p 00007000 08:01 34631 /usr/lib/libfusion-1.0.so.0.1.0
b7a94000-b7af8000 r-xp 00000000 08:01 34551 /usr/lib/libdirectfb-1.0.so.0.1.0
b7af8000-b7af9000 r–p 00063000 08:01 34551 /usr/lib/libdirectfb-1.0.so.0.1.0
b7af9000-b7afa000 rw-p 00064000 08:01 34551 /usr/lib/libdirectfb-1.0.so.0.1.0
b7afa000-b7bbd000 r-xp 00000000 08:01 34426 /usr/lib/libasound.so.2.0.0
b7bbd000-b7bbf000 r–p 000c2000 08:01 34426 /usr/lib/libasound.so.2.0.0
b7bbf000-b7bc2000 rw-p 000c4000 08:01 34426 /usr/lib/libasound.so.2.0.0
b7bc2000-b7bc4000 r-xp 00000000 08:01 2589920 /lib/tls/i686/cmov/libdl-2.9.so
b7bc4000-b7bc5000 r–p 00001000 08:01 2589920 /lib/tls/i686/cmov/libdl-2.9.so
b7bc5000-b7bc6000 rw-p 00002000 08:01 2589920 /lib/tls/i686/cmov/libdl-2.9.so
b7bc6000-b7bc7000 rw-p b7bc6000 00:00 0
b7bc7000-b7d23000 r-xp 00000000 08:01 2589914 /lib/tls/i686/cmov/libc-2.9.so
b7d23000-b7d24000 —p 0015c000 08:01 2589914 /lib/tls/i686/cmov/libc-2.9.so
b7d24000-b7d26000 r–p 0015c000 08:01 2589914 /lib/tls/i686/cmov/libc-2.9.so
b7d26000-b7d27000 rw-p 0015e000 08:01 2589914 /lib/tls/i686/cmov/libc-2.9.so
b7d27000-b7d2a000 rw-p b7d27000 00:00 0
b7d2a000-b7d37000 r-xp 00000000 08:01 2572353 /lib/libgcc_s.so.1
b7d37000-b7d38000 r–p 0000c000 08:01 2572353 /lib/libgcc_s.so.1
b7d38000-b7d39000 rw-p 0000d000 08:01 2572353 /lib/libgcc_s.so.1
b7d39000-b7d5d000 r-xp 00000000 08:01 2589922 /lib/tls/i686/cmov/libm-2.9.so
b7d5d000-b7d5e000 r–p 00023000 08:01 2589922 /lib/tls/i686/cmov/libm-2.9.so
b7d5e000-b7d5f000 rw-p 00024000 08:01 2589922 /lib/tls/i686/cmov/libm-2.9.so
b7d5f000-b7e43000 r-xp 00000000 08:01 35237 /usr/lib/libstdc++.so.6.0.10
b7e43000-b7e47000 r–p 000e3000 08:01 35237 /usr/lib/libstdc++.so.6.0.10
b7e47000-b7e48000 rw-p 000e7000 08:01 35237 /usr/lib/libstdc++.so.6.0.10
b7e48000-b7e4e000 rw-p b7e48000 00:00 0
b7e4e000-b7e5c000 r-xp 00000000 08:01 34365 /usr/lib/libXext.so.6.4.0
b7e5c000-b7e5d000 r–p 0000d000 08:01 34365 /usr/lib/libXext.so.6.4.0
b7e5d000-b7e5e000 rw-p 0000e000 08:01 34365 /usr/lib/libXext.so.6.4.0
b7e5e000-b7f48000 r-xp 00000000 08:01 34346 /usr/lib/libX11.so.6.2.0
b7f48000-b7f49000 —p 000ea000 08:01 34346 /usr/lib/libX11.so.6.2.0
b7f49000-b7f4a000 r–p 000ea000 08:01 34346 /usr/lib/libX11.so.6.2.0
b7f4a000-b7f4c000 rw-p 000eb000 08:01 34346 /usr/lib/libX11.so.6.2.0
b7f4c000-b7f4e000 rw-p b7f4c000 00:00 0
b7f4e000-b7f62000 r-xp 00000000 08:01 2572449 /lib/libz.so.1.2.3.3
b7f62000-b7f63000 r–p 00013000 08:01 2572449 /lib/libz.so.1.2.3.3
b7f63000-b7f64000 rw-p 00014000 08:01 2572449 /lib/libz.so.1.2.3.3
b7f64000-b7fcb000 r-xp 00000000 08:01 34342 /usr/lib/libSDL-1.2.so.0.11.2
b7fcb000-b7fcc000 —p 00067000 08:01 34342 /usr/lib/libSDL-1.2.so.0.11.2
b7fcc000-b7fcd000 r–p 00067000 08:01 34342 /usr/lib/libSDL-1.2.so.0.11.2
b7fcd000-b7fce000 rw-p 00068000 08:01 34342 /usr/lib/libSDL-1.2.so.0.11.2
b7fce000-b7ff9000 rw-p b7fce000 00:00 0
b800a000-b800c000 rw-p b800a000 00:00 0
b800c000-b800d000 r-xp b800c000 00:00 0 [vdso]
b800d000-b8029000 r-xp 00000000 08:01 2572311 /lib/ld-2.9.so
b8029000-b802a000 r–p 0001b000 08:01 2572311 /lib/ld-2.9.so
b802a000-b802b000 rw-p 0001c000 08:01 2572311 /lib/ld-2.9.so
bfa15000-bfa2a000 rw-p bffeb000 00:00 0 [stack]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7a2eb20 (LWP 12291)]
0xb800c430 in __kernel_vsyscall ()

Then I tried pulling from the hg src repo, but stopped there because there wasn't a configure script and my girlfriend wants to go out shopping.

Hm. A lot of people have been having problems with Schism Tracker on Ubuntu lately, but I never get anything concrete enough to track down what's going on. I might have to install Ubuntu. :/

My completely unfounded gut feeling is there might be some header/data sizeof() mismatch somewhere, but I don't really know why that would make it explode on Ubuntu and work fine on all three of my (non-Ubuntu) systems. Some kind of libc/kernel security/hardening patch, maybe? Who knows. I'll take a good hard look at all the headers and see if there's some glaringly obvious mismatch.

(btw: if configure is missing, run autogen.sh to create it)

lol @ my name

It seems to have something to do with upgrading Ubuntu; Mine worked just fine until I upgraded. Alas, it seems to happen to few other software too.

I'll have to try the autogen.sh and report back. By the way, I also noticed that in the progress of the "upgrade", many packages were destroyed (mostly being from uninstalled software, but the ones I could particularly recognize was from software I had uninstalled via Synaptec, that, I've noticed, does not uninstall dead libraries installed with the software).

Hmm... It seems I am unable to locate the autogen.sh. Oh, and to mention, I have also re-installed Schism, which also doesn't seem to work.

Any possibility for any response?

It seems as if the problem is partly on linux for "preventing stack smashing", that seems to have something to do with variables that are created and then deleted? or probably left floating, or something.

For someone who understands anything of coding, here is an example of "stack smashing"

char sendBuffer[11];
...
memset(sendBuffer, 0, 256);
scanf("%10s", &sendBuffer);

(sauce: http://ubuntuforums.org/showthread.php?t=1103586&highlight=stack+smashing )

Hopefully this helps in some way...

>>791
Well, as I don't have Ubuntu, this sort of bug is really hard for me to track down myself. I've tried, but short of manually reading through everything I really can't do much.

Any chance of delegating the duty for someone who has been designing the linux translation (there must be someone, since it has worked properly before the upgrade)?

The what?

"Duty". Probably not the best word, but best I could come up with. I do not mean that "not fixing this would be against of the code of programming", but that I believe that there are at least someone who would like to have the program working on the platform in question, and has the skills to fix it.

What I mean, is that there is an Ubuntu installer of the Schism Tracker, and I have understood installer packages for Ubuntu (or Linux in common) are fairly difficult to do, so I presume that since there is one, someone must be familiar with the platform and the code. And as "delegating the duty" I mean that the one who knows of the platform and has the skills with code, should be let be known about this particular problem, and via "official" channels, the possible outcome would be made aivable for everyone. As I would fix the problem myself if I'd know about programming.

The Ubuntu package hasn't been updated since 2007, and whoever was maintaining it appears to have abandoned it.

I have no intention of providing support for any specific distribution; however, I would have no objection to a Ubuntu user fixing the bug and submitting a patch for inclusion in mainline releases.

Fair enough...

Now it's just up to finding someone with programming and Ubuntu experience... Or figuring how can I downgrade my system (Schism seems not to be the only program that crashes on startup. And those that still work, are in danger of crashing by slightest error).

The bug is located in schism/page_patedit.c:cfg_load_patedit, where schism/config-parser.c:cfg_get_string is run with 5th argument equal or larger than size of 4th argument. This will result in the 4th char argument setting a \0 outside its bounds.

I presume the correct size is supposed to be 64, since s is 65.

change this:
cfg_get_string(cfg, "Pattern Editor", "channel_multi", (char *) s, 65, "");
to this:
cfg_get_string(cfg, "Pattern Editor", "channel_multi", (char *) s, 64, "");
save and compile:
make && ./schismtracker. works great running ubuntu 9.04! :)

Regards,
Jostein Topland

>>800
Oh, awesome. Can I buy you a beer?

... The really funny thing is, just a few lines up there's an almost identical call to cfg_get_string for the track view scheme, save the key name and the count.

>>800 fixed in git

>>803
git still exists?

>>804

hrm, well, snark attitudes aside, you didn't exactly post a message to the board or send me an email saying anything.

http://nimh.org/p/

contains patches not in hg.

i've removed my git repository.

there is so much tension here, can't we all just git along!

more importantly though there are no builds anymore, so where do we download it now?

>>806

You can build it yourself.

http://eval.sovietrussia.org/wiki/Schism:Building_on_Linux

btw: I just updated it; hopefully it's accurate again.

Looks ok to me... well, you don't really need Mercurial to build it or fetch the source – you can just as easily pull the tar.bz2 from the web repository, as it's generated straight from the latest default branch. It does help for development, of course.

I'll try to get some prebuilt packages for Linux i686 and Windows this week. My Powerbook is erm, not functioning any more, so I can't make an OS X build of any sort at the moment.

Attached is a current Win32 build. No installer, should just be able to unzip and run.

If you can get Tiger ppc up and running on it, I can give you a tarball of my mac-mini's /Developer/ and fink installs that I used to make a 10.2ppc and 10.4intel build. It's a bit hackish, but then supporting, ten years of Macintosh is bound to be.

...and yes, you don't need hg, but if you're going to build from source, you might as well make it easy to download updates.

maybe I can put a note about that on there....

>>811
Oh, sure, I have Tiger. The thing is, I have no computer to run it on – my laptop ceased booting altogether. I know it's not the power supply, because I hear the disk spin up, and if I remove all the RAM, it beeps at me. Before that the BIOS wasn't even recognizing one of the sticks, and the DVD drive never worked right. So, whatever. I broke the case open and extracted the hard drive... even though THAT doesn't work right either, it's got some sectors that would deadlock the OS upon reading.

Stupid overpriced pile of crap.

Anyway, I found some rather difficult-looking instructions on how to cross-compile for OS X, and I still have the DVD that came with my computer that has all the development tools, so I might be able to produce builds from Linux. I just need to invest some time in figuring out how.

Realistically, I don't think very many people are running pre-Tiger OS X versions anymore. Heck, most programs no longer have current builds for anything below 10.4, and some apps don't even support PowerPC nowadays. Apple moves fast, and they seem bent on making it a pain in the butt to support legacy. shrug

>>809
Thanks for the win32 ver!
CPU usage has decreased to 6-9 %!!! There were 50-70 % Earlier.
Fine!)

Nice improvement! :)

in win32 build - keyboard speed:
high response when i keep on holding the key- TRRRRRRRRRRR))))
i go to - Control Panel>Keyboard> and change "Repeat Delay" and "Repeat Rate" - no result(
again - TRRRRRRRRRRRRRRRRRRRR)))

This bug not strongly disturbs, but is swept up.

In other applications after change of parametres of the keyboard, speed of repetition varies, in schism tracker - no.
May be i can change speed in conf file?

and my hardware (If it's important):
notebook HP 6735B AMD_Athlon X2, 2G RAM, ATI Radeon HD 3200

OS: Win XP x32 SP3

Ah. I messed with the keyboard repeat recently because it was far too slow for me. :)

Impulse Tracker had a notably faster key repeat than other programs – and naturally, being a DOS app, it didn't pay attention to Windows's settings. I find it sometimes useful especially with moving the cursor around in the pattern editor, and I have gotten used to having a key repeat that's, well, slightly insane :D

I'll add an option and update the builds shortly...

Ok, new builds in with "normal" key repeat behavior, and configurable custom repeat for weirdos like me. ;)

New behavior is as follows:

• If you want Schism Tracker to act like everything else and use your system key repeat, you don't have to do anything special.
• If you want the key repeat to be different, at least for now, you have to do some manual editing of the config file. ("Rewrite preferences screen" is somewhere buried in my personal TODO list, somewhere between "save princess yet again" and "build perpetual motion machine"...)

My own ~/.schism/config contains the following:

[General]
key_repeat_delay=125
key_repeat_rate=25

Yes now all is good)))
THanks)
Yesterday there was my birthday. Schism - a nice gift)