| Comment by: samo79 (193.207.212.51) | At: 12 Jul 2024, 21:53 | File version: 1.18.2r2 |
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
|
| |
| |
| Comment by: HKvalhe (46.9.5.144) | At: 11 Oct 2020, 17:01 | File version: 1.18.2r2 |
This one is very useful to have on Amiga, even at this stage! An important work-in-progress! Keep it up!
|
| |
| |
| Comment by: Daytona675x (195.14.223.139) | At: 15 Mar 2015, 13:07 | File version: 1.7.411 |
Sorry, wrong line number: make it 188-191 instead of "around 280"... That 280 came from my analyzing-setup :P
|
| |
| |
| Comment by: Daytona675x (195.14.223.139) | At: 15 Mar 2015, 12:50 | File version: 1.7.411 |
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!
|
| |
| |
| Comment by: salass00 (91.150.28.188) | At: 01 Nov 2014, 21:26 | File version: 1.7.411 |
@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.
|
| |
| |
| Comment by: Daytona675x (87.79.213.173) | At: 30 Oct 2014, 10:11 | File version: 1.7.411 |
@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:
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
|
|
| |
| |
| Comment by: salass00 (91.150.28.188) | At: 07 Oct 2014, 10:20 | File version: 1.7.411 |
@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.
|
| |
| |
| Comment by: Daytona675x (213.168.89.178) | At: 06 Oct 2014, 13:36 | File version: 1.7.411 |
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.
|
| |
| |
| Comment by: Daytona675x (213.168.89.178) | At: 06 Oct 2014, 10:21 | File version: 1.7.411 |
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)
|
| |
| |
Audio (343)