IRC logs for #opendune on OFTC at 2011-11-03
⏴ go to previous day
00:14:15 *** Xaroth has joined #openDune
00:14:15 *** ChanServ sets mode: +o Xaroth
13:25:29 *** svuorela has joined #openDune
13:27:18 <svuorela> I have found a crasher bug, and is looking for a fix. I have figured out what goes wrong and might have some fix-ish available, but I'm not fully sure that I've gotten all details around how things work
13:28:25 <planetmaker> you might open a bug report and attach the prospective fix
13:30:52 <svuorela> hmm.... requires account on bugtracker :/
13:34:36 <svuorela> anyways. When trying to place a building and then pressing cancel, most of the time you will see a crash. It's due to accessing g_map in widget_draw.c line 472 at position 65xxx where g_map is only 64*64 long. My local patch is just setting actionType to 1 if we are at position >=64*64 before reaching line 472.
13:35:36 <svuorela> and manually compiled
13:35:42 <glx> hmm I though it was fixe :(
13:35:46 <svuorela> on 32bit debian ix86
17:56:57 *** Alberth has joined #openDune
17:56:57 *** ChanServ sets mode: +o Alberth
18:04:40 <svuorela> ..I have now a frozen opendune 0.7 in a combat situation. should I just kill it, or anyone interested/wants to play the gdb game with me ?
18:20:14 <Alberth> hmm, looks like sound
18:21:55 <svuorela> Alberth: my best guess is that the 'frame refresh timer' ticked while playing a sound so the sound bits is actually unrelated, unless something is actualy holding some internal xcb lock from the sound playing.
18:22:06 <svuorela> is opendune using threads or smething, btw ?
18:23:27 <Alberth> I was mostly involved in low-level code conversion, I never looked at how the global architecture works.
18:23:59 <svuorela> I guess I will just kill it for now and see if it happens again (and be a bit better at doing savegames)
18:24:42 <Alberth> I am pondering wether to throw it into the bug tracker
18:25:53 <svuorela> the more I look at the backtrace, the more I feel like blaming xcb rather than opendune
18:27:09 <svuorela> xcb is a part of the modern x11 client library.
18:28:34 <Alberth> ah, ok. libSDL is another player that may be messing up, no idea what it does in getting stuff displayed at the screen.
18:28:42 <glx> oh it looks like the deadlock in free()
18:30:04 <svuorela> glx: as in glibc free() ?
18:30:42 <Alberth> svuorela: one thread doing malloc and another one doing free
18:30:44 <glx> happens when free is called outside a thread calling fopen IIRC
18:52:41 <TrueBrain> that racecondition should have been solved ...
18:53:52 <TrueBrain> hmm, this is a new one, where ALSA does an unexpected alloc
18:54:02 <TrueBrain> for no obvious reason :(
18:54:19 <TrueBrain> and that would be kinda unsolvable ....
18:54:31 <TrueBrain> X11 insists on doing a free(), and ALSA does a (c)alloc ...
18:54:38 <TrueBrain> in 1 threads, that is a deadlock ...
18:54:41 <TrueBrain> in 2 threads, that is a deadlock ...
18:56:00 <Alberth> you'd need to have 1 thread doing all forms of IO, I guess
19:01:13 <TrueBrain> well, strictly is it one thread
19:01:17 <TrueBrain> but a signal in a thread
19:01:33 <TrueBrain> and sadly, nobody ever solved that issue, you cannot malloc/free in a signal, if that signal is triggered by a malloc/free
19:01:53 <TrueBrain> also, sadly, there is no way to avoid triggering signals in these cases, or to detect your signal comes from a malloc/free :(
19:02:16 <TrueBrain> I guess the only 'sane' way to solve it, would be to disable signals on ALSA calls, for that time
19:02:22 <TrueBrain> would hurt performance a bit, but ... well :P
19:04:46 <glx> the other solution would be to replace the timer loop with a real event loop
19:04:57 <glx> but that will take some time :)
19:06:31 <glx> this is also why window is not created on video driver init on windows
19:07:21 <TrueBrain> that is also because under Windows signals are more like threads ;)
19:07:29 <TrueBrain> (well, fibers, but who is counting :))
19:14:57 <TrueBrain> anyway, svuorela, please make a bug report out of it, as it is a real bug. Posting the backtrace there would be very helpful :)
19:29:05 <svuorela> TrueBrain: btw, do you have around 6 hours backlog of the channel where i was talking about a different issue ?
19:29:41 <Xaroth|Work> likely, but it helps if that one was turned into a bug report as well
19:29:53 <Xaroth|Work> for sake of having the right stuff documented in the right places
19:30:54 <TrueBrain> svuorela: I know glx already tried to fix it once, so he will be the one to talk to about that
19:31:02 <TrueBrain> but like Xaroth|Work says, make a bug report out of it, so it doesnt get forgotten
19:31:25 <svuorela> I was trying to avoid creating yet another bug tracker account, but failed horribly at that :)
19:31:26 <TrueBrain> bugs like that are easily forgotten about :D
19:31:36 <TrueBrain> downside of playing Open Source games :D
19:31:50 <TrueBrain> but much appreciated that you did ;)
19:47:08 <TrueBrain> a nice little present for glx :D:D
19:55:46 <glx> I really though it was fixed
19:56:34 <TrueBrain> the ways we tested, it was ..
19:56:38 <TrueBrain> I guess he found a new way :D
19:57:42 <glx> anyway there's surely other similar problems
19:58:00 <glx> dune2 code is not the best at checking bounds
19:58:11 <TrueBrain> that is very true :)
19:58:34 <glx> and some 65535 were -1 at that time :)
19:59:07 <TrueBrain> well, for sure one of the bigger issues is that [65537] is [1] for dune2
20:00:24 <svuorela> willl opendune ever support 'additions' like the possibility to queue up things to build ?
20:00:43 <TrueBrain> there always have been intentions to allow 'mods'
20:00:57 <TrueBrain> but development kinda stalled now we have a (mostly) stable version :)
20:01:05 <glx> it's very hard to add stuff in the current code anyway
20:01:19 <glx> we even don't understand some parts of it :)
20:01:31 <svuorela> oh. how is the code done? decompiling?
20:02:34 <Xaroth|Work> that explains a lot of it :)
20:07:54 <TrueBrain> what did you expect? :P
20:13:14 <svuorela> ...in my upgrade from 0.6 to 0.7 I have teh impression that it is has gotten worse at sounds. For example, it says 'Or Destroyed' when it should be saying 'Ordos vehicle|unit|something destroyed'
20:14:21 <TrueBrain> it should have gotten better, because there is no more remixing
20:14:29 <TrueBrain> but it is possible your soundcard does not support it ...
20:14:43 <TrueBrain> our test systems (ALSA-wise) is rather limited :D And ALSA is not known for its stability ...
20:15:30 <svuorela> it basically sounds like where it is 'glueing' sounds together, it stops sound1 too early to start sound2
20:15:57 <glx> means ALSA may not ask for data when it should
20:17:30 <TrueBrain> it is hard to compare, but it wouldn't surprise me if the pitch of your sound is too high (or low)
20:17:54 <TrueBrain> that would cause change in timing .. it is the only significant thing that changed between 0.6 -> 0.7, as far as I am aware
20:18:03 <TrueBrain> that we tell ALSA to play the voice at a certain rate
20:18:16 <TrueBrain> and I know not all drivers support that .. but I assumed only really old ones wouldn't :D
20:18:41 <svuorela> the voice sounds like it did in 0.6 and also approximately like how I remember it from 15? years ago ?
20:18:43 <TrueBrain> those who not support it, do a closest-match .. which can in theory result in what you describe :P
20:19:12 <TrueBrain> lol, if you can remember how the pitch of a voice was from 15 years ago, you are most likely a genious ;)
20:19:37 <TrueBrain> but okay, it is hard to tell what goes wrong .. ALSA works here on 3 machines (with different hardware + software) :P
20:19:44 <svuorela> the pitch needs to really be changed to make 'Atriedes' sound like 'Ar'
20:20:13 <glx> <TrueBrain> but okay, it is hard to tell what goes wrong .. ALSA works here on 3 machines (with different hardware + software) :P <-- and a lot of love ;)
20:20:46 <TrueBrain> svuorela: well, other issues can be that your ALSA driver fucks up the buffer underrun (every type of ALSA implements it differently)
20:20:56 <TrueBrain> I handle 3 types ... you might be a 4th :P
20:21:12 <TrueBrain> but normally the buffer is very small, and only a cut off A would come out
20:21:23 <TrueBrain> of course your driver can be the one that has a larger buffer ........
20:21:48 <TrueBrain> although ALSA was promoted as the unification of sound, in reality, it is the prototype how not to make a general sound system :D
20:22:07 <TrueBrain> it is by far the worst library I worked with :P
20:22:14 <TrueBrain> (including SDL and Windows :P)
20:22:18 <glx> for once windows API is better on that point
20:24:12 <svuorela> I hear openal should be great for games.
20:24:35 <Alberth> sound has always been horrible at linux as far as I can remember
20:25:09 <glx> it used to be very worse :)
20:34:49 <TrueBrain> svuorela: tbh, haven't looked passed ALSA for on linux (after SDL, which sucks even worse)
20:35:02 <TrueBrain> there is also ggi's variant .. ggs? most likely ..
20:35:19 <TrueBrain> but I know most people have ALSA installed (if not all) .. not sure about the others :)
20:36:51 <TrueBrain> and I indeed have not OpenAL installed .. so most likely many other people have neither :) Adding deps in linux is a bitch :(
20:46:57 <Alberth> it's part of the fedora packages
20:47:23 <TrueBrain> it should be in all normal distros, yeah
21:05:46 <svuorela> hmm... that deadlock isn't so rare. it has happened 3 times tonight for me so far
21:06:28 <TrueBrain> hmm .. the more you talk about your ALSA, the more I think you have a really different version :D
21:09:11 <TrueBrain> for my reference, which kernel + distro do you run, and which ALSA utils?
21:09:24 <TrueBrain> lol, that answers the last part already :D
21:09:54 <TrueBrain> owh, and which audio hardware?
21:10:01 <TrueBrain> (the linux driver, if you know it)
21:10:33 <TrueBrain> (lspci | grep -i audio)
21:11:04 <svuorela> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
21:11:42 <TrueBrain> and kernel version?
21:12:46 <TrueBrain> (and I assume debian, by the 1-4 :P)
21:14:46 <TrueBrain> PAE enabled kernel, funny :)
21:14:52 <TrueBrain> I have rev 03 of that hardware, funny enough :P
21:14:59 <TrueBrain> so I don't understand the huge difference
21:16:02 <svuorela> oh. and again. slightly different backtrace, but the end point is still the same
21:16:10 <glx> with intel it can be very different ;)
21:16:49 <TrueBrain> odd and evil stuff is at play :)
continue to next day ⏵