Assignees

Labels

Projects

Milestone

27 participants

Ever since the official launch of steam for Linux, TF2 will crash when I hit the microphone button. It will usually work the first couple of times but then it will freeze up, sort of catch itself, be REALLY slow and buggy, and then won't close without having to turn off my computer. I can Alt+tab away and shutdown but I can't even kill TF2 using system monitor.

I am also having this problem. The first time I hit the mic button TF2 stutters for a second and then recovers and works normally for ~1 hour. At some point after this steam will crash when I hit the mic button shortly followed by TF2.

This used to happen a lot in early beta but seemed to clear up after a few updates. Shortly before release the problem returned again.

Similar issue is
I will get into game use mic for 1 round and it will begin to bug out Character will lock in place looping sound if I stop using mic and than it will next time just crash to desktop and take steam with it.

I have this same issue. It occurs when playing and using the in game voice chat too frequently.
I can play for about 1 hour, more if I rarely use voice chat.
When this crash happens, it happens when the voice button is pressed, then depressed after sending voice.
Steam will crash, and tf2 notices that and blocks in loops, ant then I must kill its process.

I'll add that this happens to me when using a USB microphone (part of a Logitech Quickcam). The odd thing is that I can generally use voice communication several (dozen) times with no problems before the one time that causes the crash.

When the problem happens, the game will stutter (freeze up while looping the current audio frame for a few seconds), then it will become playable again for around 5 to 10 seconds (but with obvious graphical glitches in the HUD), then it will crash with an Engine Error dialog saying some model (different each time) was not found, and that error.mdl could not be loaded.

At this point, the current audio frame is looping indefinitely, and the GUI is unresponsive. I have to switch to a tty in order to kill the process.

I have that exact issue, though it eventually crashes away and I can restart Steam back.

@ValveSoftware Please please please fix this bug, I'm close to literally begging on the floor for anybody to fix this extreme annoyance, I really hate it when I'm speaking to people in game about how good (or bad) the team is and it's freakin' annoying as hell to be interrupted by.. a crash.

Things have actually gotten worse for me. I caved in and got an analog headset and TF2 is still doing the same thing. I have frigged around with all of my audio settings but my game still crashes after using my microphone about a dozen times.

Pulseaudio is ABSOLUTELY required for what I do, which is talk to people on Teamspeak, Skype, Youtube, etc. Because Alsa can only handle 1 audio stream without sacrificing the other, so ditching Pulseaudio is most certainly out of the question.

Okay, I think I found what the issue is. It seems steam crashes when tf2 has an outgoing voice stream (aka your microphone) and an incoming voice stream (aka someone else microphone) inputing into tf2 at once. For example, if you and some guy in the game both press the microphone button, and use them at the same time, steam will crash. However, if someone is already using their microphones, and you decide to use yours, it wont crash, and vice versa. It only crashes when you and someone else decide to use your microphones at once. This is my theory, because it seems like every time my steam crashed, it was because of this.

So a hot fix would be just to make sure you use your mic lightly, and becareful of when you use it. Until Valve/Linux resolves this issue, we just have to deal with it.

Really? Well... damn. I guess the solution would just refrain from using mic too much, or just not use it at all. I got used to using it on this one server, but my game kept crashing, so the only way to make sure I didn't habitually use my mic was to type "unbind v" into the console xD. This sucks though, the only way I can see this getting fixed is if we shove it into Valve's face...

The recent hardware report came out and said that 1.6% of users are on linux.

They started a real grass roots movement about getting of Microsoft dependence, and everybody went and bought games and started using linux. They are too concerned with porting new games to linux for new potential revenue streams it seems. Meanwhile there are games like CS:S and TF2 that basically require voice to play competitively, these games are completely useless now.

I think you guys are taking it a bit far... the game isn't completely useless, I'm very used to playing without a mic and I do fine. I'm still sticking to my theory though about the voice streams, because my game only crashed when my mic and someone else's mic were activated at once.

You cannot say "this bug isn't an issue because I don't use that feature". You are not the entire user base of this game, there are many people, such as me, to which a microphone is a vital part of a competitive FPS game.

You know that this bug affects other games that DO need a mic to play like Guns of Icarus Online?
I mean, at least playing TF2 you can not talk, but in GoIO it's just impossible, it's a 100% teamplay game and you need to talk to your crew and your team's captains.
The same with L4D2.

This is a conflict with either the microphone buffer or codec it has nothing to do with other people in the game the crash is caused by how you initialize the microphone ie, Pushing the button to activate the mic. It's for certain that if you mash the microphone button twice you are almost guaranteed a crash telling me that it has something to do with the buffer, codec, or the way the microphone is initialized from a trigger.

I find I can use the microphone on tf2 for a whole match or 2 if I play it safe so the bug consists somewhere within the input and the microphone triggering or possibly the codec.

along side this bug some other source engine games such at CSS the microphone isn't even detected once you join a server.

A user on the forums has said that removing pulseaudio and using alsa stopped things from crashing. Purely to help narrow down where the problem may be, can other people confirm that switch avoids the crash? I understand not using pulseaudio creates its own problems but by doing this experiment it may indicate that pulseaudio has a bug in it and then we can try and get them to look into it.

@gdrewb-valve I had a slightly different experience than the commenter above me. Rather than removing the pulseaudio packages, I:

Created a file at ~/.pulse/client.conf with the line autospawn = no to prevent pulseaudio from starting

Logged out and back in

Verified that the pulseaudio process was indeed not running

Verified that ALSA was working properly by opening Audacity, recording some audio, and playing it back (Note: I selected my USB microphone in Audacity as the input device to use, and left the default output selected)

Opened Steam and went to Steam's Settings (the Voice tab), selected my USB microphone as the input device, and performed the echo test there (successfully; this means the Steam client itself was working properly. I also made sure I could hear IM notification sounds.)

When I launched TF2, however, there was no audio output. Audio input settings were correctly inherited from the Steam client, and people in-game were able to hear me, but the game client produced no sound of its own.

@gdrewb-valve Thanks. I fully exited both Steam and TF2 and relaunched Steam with that environment variable set, but it didn't change things.

One interesting thing I noticed is that, in the game's current state with PA disabled (playback not working), there's another little bug that somewhat allows me to cheat a bit: Whenever someone uses voice chat, the callout bubble appears over their head and their username is displayed on the lower-right part of the screen (as usual), but neither of these items are going away now. This breaks invisibility for any spy in the game who has used voice chat in the time since I connected, since the callout bubble is always visible. It seems that the code responsible for destroying the label/callout is never getting called in this broken state. Then again, not being able to hear anything helps to balance out this advantage.

Steam uses Miles and OpenAL and so does not interact directly with pulseaudio (nor with alsa). The Steam code running is the same in both instances so that reduces the chance that the problem is in Steam.

Oh come on. The reason why we never get anything fixed and the reason Linux audio is complete crap is everyone blaming the "other" components. My other programs that use pulseaudio don't crash so why would tf2 crash. It's not pulseaudio anyway, I removed pulseaudio completely from my system and used ALSA and it still happens.

If you are lazy, please don't report that you have a "fix". TF2 forums are plagued by people with false "fixes". I'm expecting someone to say "I stuck my finger up my nose and it doesn't crash! Pick your nose while it loads and it solves the issue. Oh, and reinstall" Seems like everyone tries one thing, tests it, sees that it doesn't crash exactly the same way, feels good about how smart they are, and posts false information to the forum. :(

While I didn't try removing PA completely I tried using ALSA by simply selecting it in Steam quite often and the crashes still happen. How would that be different to using pure ALSA without having PA installed anyway? Honest question.
Judging from @doug65536's statement it seems like it was a false lead anyway.

Doesn't Miles support Linux through OpenAL only? In that case how could there be a difference between PA and ALSA as OpenAL would still be involved? Which version of Miles is Steam using? Because browsing through this (http://www.radgametools.com/msshist.htm) reveals some OpenAL specific improvements made late last year and a whole bunch of general crash fixes over the last few years.

There are user reports, such as adaricmar above, that say that removing pulseaudio fixed their crashes, so why would it be a false lead? It doesn't help everybody but that it helps some people seems like interesting information.

In the particular path where the crash is happening Steam is calling OpenAL directly, it isn't going through Miles. That may be a red herring since the problem may be something completely diferent that occurred in the past, but as a starting point it says that something in OpenAL's state is messed up.

It doesn't actually prove that it's not a pulseaudio problem as it may indeed be a pulseaudio problem for some people and there may be other issues that other people are hitting. It could easily be something entirely unrelated to pulseaudio. As we know essentially nothing about the cause of the crash it's hard to say anything definitively.

A good step would be for the people behind OpenAL to take a look since the crash is in their code so they're best positioned to comment on the immediate cause of the crash (possibly not the actual original reason, just what is broken that was the immediate culprit).

Is the issue also appearing with OpenAL 1.15? Ubuntu's is stuck on a version that's out of date and it seems like raring is on the same version. What do the crash reports say?
I'm really interested in what setups can't repro this issue at all.

I'll check the crashes, but can you catch the crash in gdb and get a stack with your build of OpenAL so that we can see exactly where it's crashing there? Are you familiar enough with gdb to do some basic debugging at the time of the crash?

I'm currently testing and a bit concerned. I don't feel like joining a VAC secured server with gdb attached to steam to do my usual repro. Is that a justified concern? Can I repro the issue with just steam friends voice chat? Is that the same?

I'm currently testing and a bit concerned. I don't feel like joining a VAC
secured server with gdb attached to steam to do my usual repro. Is that a
justified concern? Can I repro the issue with just steam friends voice
chat? Is that the same?

—
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/1853#issuecomment-16676113
.

I don't think it's happening with just Steam voice chat, had a chatty one going for over half an hour and it didn't happen. And I'm not going to test this out in-game unless I know how VAC thinks about finding gdb attached to the Steam client.

Crash bp-9d4fccab-249e-4149-9158-91e2c2130419 is still showing libopenal.so.1.13.0. How did you install your new build? If you look for the libopenal.so.1 in /usr/lib/i386-linux-gnu it should be a link to your new libopenal.so.1.15.0. If it isn't try updating it and rerun.

You should be OK running steam under gdb, If you do catch it under gdb do 'bt' to get a stack trace. Assuming it finds your symbols properly that should show you the file and source line in your OpenAL source to see exactly where it hit the problem. In the 1.13 crash sent up it's most likely a call to malloc or free, so there may be some system and libc frames before you get to the OpenAL frame.

@gdrewb-valve I had suspected that the old libs were still loaded but 1.13? That is odd, I'm running Quantal which has 1.14 in it's repos and checking my backed up OpenAL libs I'm positive that I didn't have 1.13 installed.

Ok, I just checked the steam-runtime folder and there is OpenAL 1.13 in there. That would also explain why Arch users are seeing 1.13 crashes on their cutting edge distro, I will proceed and replace that lib instead.

Here is a gist with the bt from my latest repro of the crash https://gist.github.com/DerRidda/5423273
flibitijibibo is the person I asked to make me a clean 32bit build. I'm currently still having gdb and Steam open at that precise point if there is anything more I can do with this.

Thanks, that's good information. Steam is calling OpenAL which is calling through alsa and getting into pulseaudio. pulseaudio appears to be doing an allocation.

Was there any output prior to what you put in the gist? It looks like the C runtime detected heap corruption at the time of pulseaudio's alloc and is killing the process. The unfortunate thing is that the heap could have been corrupted at any time earlier and it's just showing up now. Sometimes you'll get a piece of output indicating the address of the corrupted block, which would be a little useful. After that there isn't much to extract, corruptions like this usually require complex debugging to catch when the corruption occurs. That means somebody who can track the corruption (Valve, unless somebody in the community is motivated and knows how to do it) will need to repro this.

Thanks again for capturing this and I'm sorry I don't have a quick solution.

OK, there's no extra information. We're back to the same place of we need to reproduce in controlled conditions where we can track what's happening leading up to the problem, unfortunately. We'll keep working on that.

Actually, I am guilty of the same thing I complained about. I can confirm that with pulseaudio removed from my system, I don't get the crash. However, there is another issue with that: I have to go into steam settings every boot (once) and click "detect audio devices" OR change the device and change it back, to get the microphone to work in TF2. I had hoped that setting my USB microphone with soundrc.conf would have solved it, allowing "default" to work. This was successful but I still have to detect or change device (and change it back) before voice works. (Ubuntu 64-bit 12.10 - logitech desk microphone (AK5370), and RealTek ALC889 bigbang xpower X58 chipset motherboard audio (intel-hd-audio))

Just want to clarify since I made it confusing in my previous post: removing pulseaudio DOES fix the voice hang. I use voice a lot and I play for many hours some days so I am quite sure that pulseaudio is involved in the hangs. Sorry for adding confusion. It seems like a memory corruption because it (usually) shows "unable to load model" error dialog box if you let the hang sit for a while.

If you have updated to the latest beta client from today, here's another thing to try. First, see if the problem still happens. If so, quit Steam completely and launch with the environment variable STEAM_OPENAL_SKIP_CAPTURE=1 set. This skips Steam's call to alcCaptureSamples and instead fills Steam's buffer with zero. You will not have working voice since no audio samples are being captured, but if the crash does not occur it makes it extremely likely that the problem lies in the audio stack below Steam. If the crash does occur then it's not the sample capturing and is more likely a Steam bug.

If you try this and your voice is working (other people can hear you) then the environment variable is not having an effect, so make sure that you are heard in the crash case and are not heard after setting the environment variable.

If you have updated to the latest beta client from today, here's another
thing to try. First, see if the problem still happens. If so, quit Steam
completely and launch with the environment variable
STEAM_OPENAL_SKIP_CAPTURE=1 set. This skips Steam's call to
alcCaptureSamples and instead fills Steam's buffer with zero. You will not
have working voice since no audio samples are being captured, but if the
crash does not occur it makes it extremely likely that the problem lies in
the audio stack below Steam. If the crash does occur then it's not the
sample capturing and is more likely a Steam bug.

If you try this and your voice is working (other people can hear you) then
the environment variable is not having an effect, so make sure that you are
heard in the crash case and are not heard after setting the environment
variable.

—
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/1853#issuecomment-16987285
.

Interesting, so people are having different results with the envvar? The stack from DerRidda is messy but if parts of it are to be believed things are still crashing in pulse, just along a different code path that the new envvar doesn't affect, so it doesn't add much info. However, if things no longer crash for NothingMuchHereToSay with the envvar set it is having at least some effect. We'll probably need to try and get the pulse people involved to look from their side.

I'm skeptical if @NothingMuchHereToSay actually tested for long enough and would highly recommend he test again for a prolonged time. Keep in mind you actually have to keep using voice chat just as much as you would if it was still enabled and that the time it takes for it to happen is highly variable.

@DerRidda It all depends on how often the server communicates, but I thought @gdrewb-valve said that voice chat isn't possible with that environmental (or whatever that is) set. Then again, I'm not sure how to properly set it, do I put "steam" at the end of the command or do I have to set it before I launch steam?

@NothingMuchHereToSay Just open a terminal window and enter "STEAM_OPENAL_SKIP_CAPTURE=1 steam" without the quotation marks of course. To test if it worked go into the Steam settings voice tab and test the microphone, you shouldn't hear a thing and the level meter should also not be moving. When testing your microphone in your operating system's audio settings it should work as intended, though.
After that just start playing CS:S or another Source game online and make liberal use of push to talk.

To not feel like a complete fool while talking to yourself I recommend making snarky comments about other players that would normally get you kicked. ;)

@DerRidda Honestly, after spending about an hour of talking on Turbine with the "STEAM_OPENAL_SKIP_CAPTURE=1 steam" option up, I haven't experienced a crash. I don't know what it could be other than maybe Pulseaudio, but I can't live without it, as without Pulseaudio, ALSA supports only one stream out of my speakers. Which is bad for multitaskers that use Teamspeak to communicate.

EDIT: Just to let you know that nobody could hear me, so I know that the envvar was set.

@Nemoder: I also didn't have any luck with disabling shared memory in that config file, still the very same behavior for me. Did you play around with any other option in the pulse config files by any chance?

@gdrewb-valve Even with the underlying cause of the audio/pulse failure unknown, shouldn't it be possible with the submitted crash reports to at least prevent the client from crashing when the situation arises? My impression is that PulseAudio or OpenAL is behaving in some way that the client isn't prepared for, and that it may be possible to simply bolster the client by sanity-checking what's coming in at the point of failure (and just printing some kind of error to the game console: "Error: OpenAL did something bad!"). It would be better to just lose voice communication than to get pulled out of the game entirely.

That said, things could certainly be more complicated than my first impression, and the above could be easier said than done.

The bug is still happening when running the steam beta with STEAM_OPENAL_SKIP_CAPTURE=1 steam
I spammed my mic button nonstop while playing and it happened after 10 minutes.
Going to play now without touching the mic button.

I've read the entire thread, as I have recently started playing Guns of Icarus Online, and got about 14 hangs in a period of three hours. Uninstalling PA isn't an option for me - it's really ingrained in the Ubuntu desktop, and I don't want to deal with the mess that happens without it (I also use a USB headset).

So I've went to Steams Settings, Voice, and set it to use my USB headset for voice input via ALSA - not PulseAudio like it offered. My voice still works and the game hasn't hung yet!

Setting the voice input to ALSA doesn't help here aswell.
Steam still uses PulseAudio for voice input and output.
And when setting SDL_AUDIODRIVER to ALSA Counter-Strike: Source uses ALSA for output but voice input is still going through steam and crashes it pretty often.
That really is starting to piss me off since it happens at least 10 times a day. I thought switching to pulse was a step forward, not behind.

Can anyone else who plays Guns of Icarus Online confirm what I've found? It could be that there's a difference between how TF2 and this game use the voice API. I really haven't had a crash since, and was getting them very regularly before.

I've been playing Guns Of Icarus today without crashing.
I'm using the beta version of Steam, under debian testing (amd64), and with the output set to use ALSA instead of the default PulseAudio as stated by vadi2 a few comments before.

However I didn't have time to test it enough to feel that the crash won't occur again. As son as I can I'll try to test it more.

The crash bug is still persistant and it happened to me more than 10 times today and I just removed pulseaudio and switched to alsa.
Couldn't stand playing like this anymore.
Please update when you've fixed this issue so I can test it.

@gdrewb-valve: This is a routine inquiry asking about any progress in tackling this issue.
It's 4 month since the first reports appeared and I would rather not have it become a two digit number.

Has any cooperation with the PulseAudio and/or OpenAL devs happened? I have been following the Steam beta client change log and the only thing I was hoping to see on there was at least an experimental fix regarding this issue. Now that the beta client has been pushed out to stable I really hope the next beta run will try to find means to at least circumvent this specific problem.

I don't have any good news for you. We haven't gotten any engagement from pulseaudio and things are stalled. It's difficult to impossible for us to work around the issue since we don't know what's going wrong to work around (other than the heavy-weight workarounds detailed here).

I'm sad to see this problem have gone unfixed for so long. Is there any way we can help in getting the attention from the guys at PulseAudio? We probably can't file a bug report, and spamming them is not an option either, but we may be able to assist @gdrewb-valve by showing how many are affected by this. In the end, it's exactly things like these that will decide the fate of the future of gaming in Linux. @gdrewb-valve have you not received any answer at all from the PulseAudio guys?

It's a bit early too tell, but I think using SDL_AUDIO=alsa fixed the crashing without screwing up my audio setup in Ubuntu 13.04. I also got the microphone working after trying different devices within Steam. I'll report bug when I've done some more testing. For now, sleep.

In the Steam settings I set my input to "ALSA Default". I thought I had fixed it, because I was able to talk with folks just fine in TF2. But unfortunately after about an hour of playing the game stuttered, I stopped being able to talk and hear people. I was able to play for maybe another 15 and then both TF2 and Steam crashed.

For those posting about success when choosing ALSA as an input source in steam: does your microphone continue to function(i.e. players can still hear you) when switching to a different server or changing a map?

@gdrewb-valve: After all these other fine gentleman have pointed out setting the Steam voice settings to use the very specific ALSA device instead of just "ALSA default" I tried it myself in CS:S and it actually seems to work. Do you know what the difference between the two is?
Would that be a solution? Omit all the PulseAudio options and the "ALSA default" setting from just the voice options and "force" Steam/the user to pick a specific ALSA device, that is.

I'm pretty sure picking ALSA in voice won't help. It is just an illusion that pulseaudio presents to programs - pulseaudio is still in control of the audio. Can someone confirm that picking ALSA and playing for hours straight with lots of mic use doesn't crash? It crashes for me. Also, when I do that, I have to repeatedly click DETECT DEVICES then TEST MICROPHONE, until it starts working. Usually 3 or 4 times at least. If I don't, the mic doesn't work. Even with pulseaudio uninstalled it is like that.

Since I first posted here I've switched to a different distribution of Linux, I was on Ubuntu 12.10 and now I'm on Linux Mint 14 (MATE desktop) 64 bit. The crash is still essentially the same, but now, it is slightly different.

On Ubuntu, the crash resulted in an endless hang. On Linux Mint, what happens is, it freezes momentarily, then the display at the top that shows the F4 checkboxes has 2x more people (12 if there are 6 players, with the second 6 being duplicates of the first). It's definitely a memory corruption.

After the memory corruption, mic stops working, the game resumes running, and after a while, the server kicks me with a message "You must be logged in to Steam" (and I still am logged in to steam).

I've since removed pulseaudio and I don't have the problem. This is definitely not a good solution, because I can't record screencasts this way (I use ffmpeg to record games, and I need pulseaudio to be able to capture game sound).

If I were on the TF2 development team, I would find what variables would cause the players display at the top to be doubled, and set a hardware data breakpoint one of those variables. That or perhaps a variable involved with checking if the player is still logged on to steam. With a bit of luck, your machine will break into the debugger with the exact call stack that is causing the issue (right at whatever instruction is clobbering that memory).

Forget the pulseaudio people, they won't help. They will deny it and give you a list of excuses and other things to blame, like the game itself, ALSA, your audio driver, your kernel, your hardware, etc. From what I've seen, they take any criticism or issues with pulseaudio personally. All professional software developers know, all code has bugs. Usually lots of bugs.

@doug65536: Don't be too dismissive of the ALSA setting, I tried to set it to "ALSA default" plenty of times before but that didn't change a thing but for some reason that is totally beyond me selecting the device directly seems to be different and has also seemingly fixed it for me, with PulseAudio still installed of course.
So far I have played several 2+ hours sessions of CS:S with heavy voice usage, multiple map changes and not encountered the problem again while this time frame usually was enough to trigger the crash under PulseAudio.

About that DETECT DEVICES and TEST MICROPHONE behavior: Yes, when selecting the specific ALSA device it behaves the same for me, for some reason half the time the test won't work unless I click detect devices again but in-game it works all the time, seems to be more of a Steam derp than an actual ALSA problem.

I strongly recommend that you install PulseAudio again and try it this way yourself, we need more people to test this and report back as many people will just stop communicating as soon as their issue disappears for them.

I have played many hours without any crashes in both Garry's mod and CS:S. It does not break system-audio, nor does it function any differently in-game. It just works. I have had one of those loop-freezes, but the game survived and so did Steam and therefore voice-chat. Test microphone does seem to be a little unpredictable, but others can hear me fine all the time.

While I'm disappointed that this issue has yet to be fixed, whether it's because of Steam or PulseAudio (I wouldn't wonder if PulseAudio would just ignore it, they do seem pretty dismissive about any issues), I'm glad I can at least play properly now.

@McAndze I'm sorry to say this but you're wrong.
I tried this a while ago and retried it right now.
I've set the audio device in steam to ALSA and started it through SDL_AUDIO=alsa steam.
I've opened pavucontrol on my second screen and tried out the mic test in steam itself: it uses Pulse
Tried with the test in the steam overlay: it uses Pulse
And last, I tried it ingame and: it uses Pulse
Every time I use my voice activation key it opens a new audiostream in the record tab of pavucontrol.
Even though counter-strike uses ALSA for outputting sound.

Well, that'd require some testing but since it still relies on pulse and none of the devs said that this issue has been resolved I guess it does crash.
I tested it before and it was crashing so I'm pretty sure it'll still do so.
I can test it, though I have to learn right now and rather not play games :P

Are you absolutely certain that you explicitly selected the ALSA device that corresponds to your microphone in the Steam settings' voice tab? As was stated before "ALSA default" will not work.
I doubt because of how casually you just wrote "I've set the audio device in steam to ALSA".

I'm asking again because everyone that has tried it so far has no crashing problems anymore including people that are not following this issue.

@BotoX While it may not work for you, I am not wrong. I haven't had a single crash after doing this. I do not know exactly what effect this has on anything, as it is still using PA, but I know it makes a difference. I haven't had a single crash since I set up Steam this way.

Oh dear, is anyone else experiencing crashes again with the ALSA device work around in use since the latest Steam client updates? Because I am and it's happening in way shorter time frames than all the time I have used it before when it was still working.

Seems like false alarm but an interesting discovery came out of this:
i was using mumble before I started playing CS:S during which I saw these crashes again. Turns out Mumble didn't seem to have quit properly and there was still a speex-dispatcher process running, as soon as I killed that process manually the crashes went away again.

I don't know if anything of value can be deduced from that but i thought I'd mention it.

when using voice chat in guns of icarus. (the last part of the output means something like the device or resource is occupied)

In the background, I had mumble running, with voice activation.
Don't know if mumble makes a difference, maybe it's a problem that steam/guns of icarus and mumble are in some sort of a race condition for the device?

Just a bit more info for tracking: a user posted on the Steam forums that they're actually seeing PulseAudio fail with out-of-memory. Apparently pulse then aborts the process, which is very unfriendly behavior.

Unfortunately no, as we have no visibility into what PA is asking for, plus it's hard to estimate when a memory allocation will fail in general. Even if we knew when a problem would occur the best we could do would be to simply stop using voice chat since we don't have a way to prevent an allocate in the guts of PA. That's a bit better than crashing but not a great user experience.

We will apply that in the Steam runtime version of PA. That will definitely fix the Assertion 'b' failed issue, but whether it fixes everything is unclear. I know some people here have built their own PA, if somebody's interested and applies the patch and overrides the Steam runtime PA please let me know how it goes.

Hmm, well that's the biggest amount I could find in smaps. It was taking up at least a few gigs of my RAM and leaking, I'm positive of that. Disabling shm on PulseAudio stops the crashes but voice still fails, it actually breaks my PulseAudio config.

I was unaware that the Steam runtime overrides PulseAudio, I'm running PulseAudio 4 on my system.

Removing any libraries with the name 'pulse' in them in the Steam Runtime doesn't fix this. That's on the assumption it falls back and uses my PulseAudio 4, as that patch was supposedly included in PulseAudio 3.

Something triggered GDB so I assume it was a crash. If it's not, then it's odd that it closes afterwards?
The game itself is fine after mmap fails, however you can't play due to Steam auth tickets not working.

I wasn't sure on the gdb, thus my question. Did gdb have any other info at the point it became active? Usually it'll indicate the event that work it up, like a SIGSEGV or SIGILL mentioning an abort or that kind of thing.

In my case, the microphone crash happens regardless of whether I run steam with SDL_AUDIO=alsa or not. And all I do is start playing TF2, use voice chat for approximately 30 minutes and then steam crashes (not tf2, but it is unplayable since servers often require that steam is running). If you'd like I can run it with gdb tonight and see what output I get.

Just to make sure, is there a beta with updated PA libs out yet? I'm seeing a tonne of crashes in GoI, so I'll be very interested in having it fixed. Alternatively, the bug referenced says it should be fixed in PA 3.0, which my distro (Mint 15) does have. Will just removing the steam runtime packaged libs be enough to make it pick up the system libpulse?

Yes, if you remove the Steam runtime libs it should fall back on the system libs. You can verify using the command 'cat /proc/pid/maps | grep pulse' on Steam's pid. Note that the 'b' assertion is the only thing affected by that patch. The segfault that Jookia is seeing is something very different and I don't know what the cause of that is, nor have I reproed it so far. If you are getting regular crashes and can catch them in gdb does the stack look like Jookia's above (or at least is it a SIGSEGV)? Alternately, if Steam is catching and reporting the crashes to Valve do you have a crash ID I can verify with?

I don't believe yesterday's client beta has the PA update yet, but it should be coming soon.

The dump doesn't have a ton of info in it beyond the stack, so your post of the gdb stack was just as helpful. What we really need, and what a snapshot won't show, is how we got into the bad state where an invalid pointer is being used in memcpy. When I asked for a dump/gdb I was targeting that more at HaskellElephant and mathrick so that I can get an idea of whether they're seeing the same segfault as you (Jookia) or something else, like the 'b' assert.

Gotcha. I've already tried removing the runtime libs, and I can indeed confirm that it's picking up the 3.0 system libs, which would normally mean I'd be testing with reckless abandon, but my internet has been too crappy to allow any kind of networked play. I have not hit Jookia's crash yet. If I do, I might try getting my hands on a copy of UndoDB, which is the nifty GDB variant that allows going back in time. The bad news is that it's not free; the good news is that they have free of charge hobbyist trials for non-commercial uses. So anyone who isn't a Valve employee can try getting an evaluation copy at http://www.undo-software.com/.

Using ALSA (on a PA system, so still PA internally) devices I've not registered a crash in my limited playing I could do due to the internet woes; however I'm not sure I can actually get any voice to transmit during GoI matches. I know it works in the lobby, but during the matches I get the impression nobody can hear me. Will test further.

Using PA default device, I get a segfault now. CrashID=bp-52f80875-6011-4c21-a6f1-afdf82130814. Didn't try under GDB so far.

Running garrysmod, the problem seems to be related to when I start speaking
at the same time as somebody else, but I have not been able to proove or
reproduce this.
On Aug 14, 2013 11:29 PM, "Drew Bliss" notifications@github.com wrote:

The reported crash looks very similar, a segfault in memcpy, so you don't
need to get a gdb stack. All you did was run TF2 and talk, correct? How
long did it take, roughly the same 30 minutes?

—
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/1853#issuecomment-22668396
.

I believe I've found the cause of the voice-related memory leak, the next Steam client beta will have a fix for it. Whether that ends up addressing the segfault or not is unknown as I haven't been able to get it to happen.

FWIW, about an hour of play in GoI registered no crashes either. To be perfectly clear, that was with pulse libs removed from the runtime (ie. using system-wide pulse 3.0 libs). I will test with runtime-provided 1.1 and report that.

FWIW, about an hour of play in GoI registered no crashes either. To be
perfectly clear, that was with pulse libs removed from the runtime (ie.
using system-wide pulse 3.0 libs). I will test with runtime-provided 1.1
and report that.

—
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/1853#issuecomment-22708305
.

@MrPopinjay , we've made a couple of fixes and initial results look encouraging. As long as you update to the latest Steam client beta you can run with pulseaudio normally. If anybody is still seeing problems please post here, otherwise I'll close this bug (at last!).

If that's the case are you finally going to enable voice chat in L4D2? ( Unless I'm mistaken and it hasn't purposefully been kept disabled to cut down on reports on this issue.)
I haven't tested this myself enough myself yet because I have no reason to touch CS:S after the latest CS:GO update hintsayhellofromthelinuxcommunitytothecsgocabalhint but as it seems it is time to say: Finally, my most often encountered and most hated bug got squished! Well done!