openal-soft.lha development/library/audio - Comments

samo79 (193.207.212.51) @ 12 Jul 2024, 09:53.13

Fri, 12 Jul 2024 21:53:13 +0200

By: samo79 (193.207.212.51)

It would be nice to have an update, the current release seems a bit untested and we noticed some problems with certain projects, for example with the porting of Woof

HKvalhe (46.9.5.144) @ 11 Oct 2020, 05:01.32

Sun, 11 Oct 2020 17:01:32 +0200

By: HKvalhe (46.9.5.144)

This one is very useful to have on Amiga, even at this stage! An important work-in-progress! Keep it up!

Daytona675x (195.14.223.139) @ 15 Mar 2015, 01:07.30

Sun, 15 Mar 2015 13:07:30 +0100

By: Daytona675x (195.14.223.139)

Sorry, wrong line number: make it 188-191 instead of "around 280"... That 280 came from my analyzing-setup :P

Daytona675x (195.14.223.139) @ 15 Mar 2015, 12:50.59

Sun, 15 Mar 2015 12:50:59 +0100

By: Daytona675x (195.14.223.139)

Hi, 
I got no reply so far, so I post it here as well: 
during analyzing LoadConfigFromFile in alcConfig.c in search for that crash again I found this: 
the loop around line 280: depending on (random) RAM content and config file content the loop's ending condition won't be satisfied before "i" underflows (and once it does all it may run "forever"). 
This happens if the config file contains a line like this: 
stereodup =  # comment 
a line without a value - and such files exist, one I got from somebody with that crash contains such a line. 
The mem-write right after the loop is the final nail into the coffin here, since "i" may be anything now but not a valid index anymore. 
Fix: for example change the loop's content from 
i--; 
to 
if(!i--) break; 
Thanks!

salass00 (91.150.28.188) @ 01 Nov 2014, 09:26.51

Sat, 01 Nov 2014 21:26:51 +0100

By: salass00 (91.150.28.188)

@Daytona675x 
I've put up a pretty much untested version of OpenAL 1.16.0 here that you can try: 
https://dl.dropboxusercontent.com/u/26599983/openal-soft-1.16.0.7z 
 
If you find any questions or problems with it please contact me by e-mail instead of using the comments here. My address is fredrik at a500 dot org. 
 
The latest OpenAL 1.16.0 refuses to compile with as old a gcc as 4.2.4 so I had to build a newer gcc cross-compiler (4.9.1) first in order to be able to compile it at all.

Daytona675x (87.79.213.173) @ 30 Oct 2014, 10:11.02

Thu, 30 Oct 2014 10:11:02 +0100

By: Daytona675x (87.79.213.173)

@salass 
Thanks for checking! 
Yes, you're right of course, the free(NULL) is harmless on this OS. 
I'm definitely wrong here. Was my first idea because I used to work on OSes were free(NULL) crashs :) Sorry. 
Sadly I cannot provide an alsoft.conf file that crashs because it got deleted before I had a chance to look at it :( 
But I can give you a stack-trace at least: 
 
[code] 
Crash occured in module kernel at address 0x01410DD4 
Type of crash: unknown exception 
 
Register dump: 
GPR (General Purpose Registers): 
0: 01417DB4 589A84B0 00000000 01410DEC 598C9C40 01DAA7DC 01DAA7CC 01DAA840 
8: 00000001 00000000 00000001 80000017 00000164 56CF6420 569EF1AC 569EF244 
16: 569EF1AC 569EEAB4 58B2BB20 569EEAB4 56DDF03C 56DDF03C 56CEE6A0 58B2BB4C 
24: 58B2C190 56DDE3E8 589A84A0 00000001 01DBDC66 598C9C40 01CA9C48 00000001 
 
 
FPR (Floating Point Registers, NaN = Not a Number): 
0:             0.05                1                0                0 
4:                0             63.8             63.8                0 
8:              438        0.0285714       4.5036e+15       4.5036e+15 
12:       4.5036e+15       4.5036e+15                0                0 
16:                0                0                0                0 
20:                0                0                0                0 
24:                0                0                0                0 
28:                0                0                0                0 
 
FPSCR (Floating Point Status and Control Register): 0x82004000 
 
 
SPRs (Special Purpose Registers): 
Machine State (msr) : 0x0002B030 
Condition (cr) : 0x56420608 
Instruction Pointer (ip) : 0x01410DD4 
Xtended Exception (xer) : 0x56853B2C 
Count (ctr) : 0x5FF924D0 
Link (lr) : 0x6FB72918 
DSI Status (dsisr) : 0x564203C0 
Data Address (dar) : 0x015AAFCC 
 
 
 
680x0 emulated registers: 
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
FPU0:                0                0                0                0 
FPU4:                0                0                0                0 
 
 
 
Symbol info: 
Instruction pointer 0x01410DD4 belongs to module "kernel" (HUNK/Kickstart) 
 
Stack trace: 
native kernel module kernel+0x00010dd4 
native kernel module kernel+0x00017cd4 
native kernel module newlib.library.kmod+0x00013ef0 
native kernel module newlib.library.kmod+0x0000bf44 
LoadConfigFromFile()+0x578 (section 1 @ 0x154BD0) 
ReadALConfig()+0x7c (section 1 @ 0x154DCC) 
InitAL()+0xec (section 1 @ 0x14BD48) 
alcOpenDevice()+0x3c (section 1 @ 0x14C5FC) 
_ZN2GC12SoundManager4InitEv()+0xf8 (section 1 @ 0xAFBB0) 
_ZN2GC11GameManagerC1Ev()+0x2b4 (section 1 @ 0x983AC) 
_ZN2GC11GameManager6AccessEv()+0x1c8 (section 1 @ 0x989C8) 
main()+0x5bc (section 1 @ 0x90B8) 
native kernel module newlib.library.kmod+0x000020ac 
native kernel module newlib.library.kmod+0x00002d5c 
native kernel module newlib.library.kmod+0x00002ef0 
_start()+0x170 (section 1 @ 0x16C) 
native kernel module dos.library.kmod+0x00024bb0 
native kernel module kernel+0x0003b4b0 
native kernel module kernel+0x0003b530 
 
PPC disassembly: 
01410dcc: 60630dec   ori               r3,r3,3564 
01410dd0: 44000002   sc 
*01410dd4: 4e800020   blr 
01410dd8: 7c641b78   mr                r4,r3 
01410ddc: 3c600141   lis               r3,321 
[/code]

salass00 (91.150.28.188) @ 07 Oct 2014, 10:20.30

Tue, 07 Oct 2014 10:20:30 +0200

By: salass00 (91.150.28.188)

@Daytona675x 
 
Thanks for reporting, I will look into this when I update the OpenAL Soft port (latest version as of now is 1.16.0). 
 
free() on a NULL pointer should be a harmless no-op though.

Daytona675x (213.168.89.178) @ 06 Oct 2014, 01:36.40

Mon, 06 Oct 2014 13:36:40 +0200

By: Daytona675x (213.168.89.178)

Ah, well, forget that buffer-underrun issue. After taking a second look the lines 152-153 prevent that from happening. 
Anyway, that line 193 is no good and results in a Guru.

Daytona675x (213.168.89.178) @ 06 Oct 2014, 10:21.26

Mon, 06 Oct 2014 10:21:26 +0200

By: Daytona675x (213.168.89.178)

Lib likes to crash when parsing alsoft.conf files. 
Only took a quick look at the source in alcConfig.c and spotted two issues explaing the crash: 
 
Lines 188-191: potential buffer-underrun. Check for i>=0 before isspace. 
Line 193: free(null)