Hively Tracker segfaults on the Open Pandora (GNU/Linux ARM) when playing mods

[sviscapi]

Hi Pete,

I managed to compile the SDL port of Hively Tracker on the Open Pandora. Unfortunately, it segfaults when trying to play a mod file.

I'm not a developer, but with some help I think I could run gdb on the binary or on some core dump.

Here are my relevant modifications in sdl/Makefile.pandora:

ifeq (armv7l,$(shell uname -m)) BASELIBDIR := /mnt/utmp/codeblocks/usr/lib CFLAGS += -Ofast -pipe -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -fsingle-precision-constant -fuse-ld=gold -fuse-linker-plugin -fdiagnostics-color=auto -fsigned-char -mneon-for-64bits -mvectorize-with-neon-double #LFLAGS += endif

CFLAGS += -g $(shell PKG_CONFIG_PATH=$(BASELIBDIR)/pkgconfig pkg-config sdl --cflags) $(shell PKG_CONFIG_PATH=$(BASELIBDIR)/pkgconfig pkg-config gtk+-2.0 --cflags) LFLAGS += -lm -L$(BASELIBDIR) $(shell PKG_CONFIG_PATH=$(BASELIBDIR)/pkgconfig pkg-config sdl --libs) $(shell PKG_CONFIG_PATH=$(BASELIBDIR)/pkgconfig pkg-config gtk+-2.0 --libs) -lSDL_image -lSDL_ttf -lfreetype -lz -lX11

Cheers, Sam

[sviscapi]

Hi @pete-gordon :)

Some news regarding this issue thanks to gdb:

Thread 1 "hivelytracker" received signal SIGSEGV, Segmentation fault. 0x400d3054 in SDL_UpperBlit () from /mnt/utmp/codeblocks/usr/lib/libSDL-1.2.so.0 (gdb) bt #0 0x400d3054 in SDL_UpperBlit () from /mnt/utmp/codeblocks/usr/lib/libSDL-1.2.so.0 #1 0x0001384c in bm_to_bm (src=0xca928 <about_bm>, sx=-4, sy=-4, dest=0x61f4c <mainbm>, dx=236, dy=176, w=328, h=248) at ../gui.c:683 #2 0x0004cfd4 in about_handler (gotsigs=0) at ../about.c:506 #3 0x00012c14 in main (argc=1, argv=0xbeffe884) at ht.c:126

Do you understand what's wrong ?

Cheers, Sam a.k.a Magic Sam from the Open Pandora community

[SamuraiCrow]

There may be hard-coded coordinates in the themes. What resolution does a Pandora use?

[sviscapi]

Hi @SamuraiCrow :)

The Pandora uses a 800x480 resolution, do you think that could be the root issue ?

Cheers, Sam

[SamuraiCrow]

Hi Sam,

I know that the GTK2 version of the user-interface makes an unresizable window on the systems that it does work on. I'm pretty sure it uses a 640x480 resolution. If you see a build option for a full-screen mode, try it.

Cheers, Another Sam :)

[sviscapi]

Hi Sam ;)

I found this in sdl/ht.c:

// Try to setup the video display #if defined(WIN32) || defined(__APPLE__) || defined(__linux__) // requesters cause all kinds of problems for fullscreen on windows and OSX, so ignore it ssrf = SDL_SetVideoMode( 800, 600, srfdepth, SRFTYPE ); #else ssrf = SDL_SetVideoMode( 800, 600, srfdepth, pref_fullscr ? SDL_FULLSCREEN : SRFTYPE ); #endif if( !ssrf ) { printf( "SDL video failed\n" ); return FALSE; }

Looks like the resolution is hard coded... Do you think changing it to 800x480 would work ?

Cheers, Sam ;)

[SamuraiCrow]

Hi Sam,

Unfortunately not. I think the GUI is hard-coded to a fixed resolution so changing it from 800x600 to 800x480 will not work. :-(

Sorry, Sam

[sviscapi]

Hi all :)

@SamuraiCrow and @pete-gordon : some news from the Pandora front !

https://pyra-handheld.com/boards/threads/planet-hively.80353/#post-1428329

One of the most talented member of our community, ptitSeb, has found what's causing the segfault:

The issue is "just" that SDL cannot get a buffer as small as the traker wants. And no check is done to see if the wanted buffer is exactly obtained. To fix, simply change line 75 of replay.c from

#define OUTPUT_LEN ((FREQ/50)*2) /* Linux can't cope with buffer being too small, so we sacrifice GUI responsiveness... */

to

#define OUTPUT_LEN ((FREQ/50)*4) /* Linux can't cope with buffer being too small, so we sacrifice GUI responsiveness... */

And it will not crash anymore. But there maybe so other place to adjust this *2 to *4, I'm not sure (and I haven't checked)

I tried this and it worked :) I compared this build to Hively Tracker 1.6 running on MorphOS 3.9 / iBook G4 and I found the sound quality to be rather bad though (I'd say it "crackles") and the tempo is slightly off.

Any help fixing these remaining issues would be greatly appreciated ;)

Cheers, Magic Sam

[mywave82]

Easy test to verify buffer boundaries, is to run the application using valgrind. It will run VERY slow, but it will give output with backtrace whenever a heap buffer access is out of bounds, and similar issues.