Page 2 of 10 FirstFirst 1234 ... LastLast
Results 11 to 20 of 99

Thread: How NOT to write a shared library

  1. #11
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    Quote Originally Posted by public_void View Post
    I never said you should call exit().
    Ok, then we're in agreement. I thought you were justifying a shared library function handling error checking by "on OOM, terminate", because that's what I was objecting to about pa_xmalloc's "error handling".

    I do also agree with Wy that a shared lib function should not display any error messages (unless the app has given permission to do so). For one thing, if it's a GUI app, it may not even have stdout/stderr going anywhere (but nul or wherever -- but nowhere that it would be useful to an enduser using a GUI app). The app may prefer to display an error message to the enduser in a way that is applicable to the app. (For example, a GTK app may want to use gtk_message_dialog_new).

    A shared lib function should return an error code to the app, and let the app decide how it wants to deal with the error.

    After reading the code xmalloc.c the author does write to stderr.
    What else does it do? Specifically, what does the PA_GCC_NORETURN define expand to? Is it a call to exit()? If so, is PA_GCC_NORETURN used in even more places?

    Edit: Nevermind, I finally traced it down. It defines to __attribute__((noreturn)) which in turn does indeed yield a call to exit(). (Actually, it may not write to stderr. What is does is call abort() and then exit(). abort() is applicable only if code is compiled with debugging turned on. abort() typically presents an error message. But in release code, abort() defines to nothing. And I imagine that only release code would appear in a release distro. So you don't even get an error message in the release code. It just terminates the app without notice nor explanation),

    So, how many other Pulse Audio functions use PA_GCC_NORETURN themselves, and how many other Pulse Audio functions make their own calls to pa_xmalloc?

    I really hope the Ubuntu devs are not considering using Pulse Audio as part of the default install. This has the potential to seriously affect system stability and usability as a running app can just randomly vanish into a puff of smoke, perhaps taking an enduser's work with it.
    Last edited by j_g; November 15th, 2007 at 04:02 AM.

  2. #12
    Join Date
    Mar 2005
    Beans
    6,040

    Re: How NOT to write a shared library

    Quote Originally Posted by j_g
    I really hope the Ubuntu devs are not considering using Pulse Audio as part of the default install. This has the potential to seriously affect system stability and usability as a running app can just randomly vanish into a puff of smoke, perhaps taking an enduser's work with it.
    Why just hope? Why not file a bug, and/or post your objection to the development mailing lists, so that it will have some actual effect on the process?

  3. #13
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    Quote Originally Posted by 23meg View Post
    Why not file a bug
    Well, it's not a bug (and I'm sure the original author doesn't consider it to be so, because he deliberately coded it to do what it does). It's simply a design that I consider to be lacking in stability and usability.

    post your objection to the development mailing lists, so that it will have some actual effect on the process?
    I posted my objection in a forum here that is supposed to be specifically for providing the Ubuntu developers "feedback" about what features to add to Ubuntu.

    I also posted this thread here, not because I want to rag on the Pulse Audio developer (I would have greatly preferred that it had been what I was looking for), but because I want to alert other Linux developers who may decide to use Pulse Audio, or design a shared lib using similiar error handling techniques, of the perils of such a design. I also want them to be aware of the potential for increased instability and usability if such code should make it into the kernel, so that they too can be aware of this, and register their concern as well.

    I would hope that someone on the Ubuntu developer team occasionally reads programming forums here, if to do nothing more than find out what app developers do, and don't, find troublesome, helpful, easy-to-use, difficult, worrisome, etc.

  4. #14
    Join Date
    Jun 2006
    Location
    CT, USA
    Beans
    5,267
    Distro
    Ubuntu 6.10 Edgy

    Re: How NOT to write a shared library

    so you want to talk about the problem, but not help to solve it?

  5. #15
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    Alerting people to a potential problem is the best way to avoid it. There's an old saying that an ounce of prevention is worth a pound of cure. That is the "solution".
    Last edited by j_g; November 15th, 2007 at 05:58 AM.

  6. #16
    Join Date
    Apr 2006
    Location
    Chicago
    Beans
    1,405
    Distro
    Ubuntu Intrepid Ibex (testing)

    Re: How NOT to write a shared library

    Has anyone had a program vanish while using pulseaudio because of this "problem"? Hasn't happened to me on Fedora 8, yet. In every Linux distro I've tried I've had apps just up and die, but nothing is perfect. Maybe this is all some developer mumbo-jumbo thats super important, but it seems pretty small to me especially since you haven't experienced this doomsday you speak of. In fact I've never heard of anyone having a problem, caused by pulseaudio, like what you describe. I'll keep my eyes on what happens with fedora 8, but you may want to put the gun down for now.

    Also, I don't think pulseaudio is suppose to replace ALSA... I don't even think it can, were you talking about the ALSA dmix plugin?
    Constant development is the law of life, and a man who always tries to maintain his dogmas in order to appear consistent drives himself into a false position - Mahatma Gandhi

  7. #17
    Join Date
    Oct 2006
    Location
    Austin, Texas
    Beans
    2,712
    Distro
    Ubuntu 7.10 Gutsy Gibbon

    Re: How NOT to write a shared library

    Quote Originally Posted by hanzomon4 View Post
    Has anyone had a program vanish while using pulseaudio because of this "problem"? Hasn't happened to me on Fedora 8, yet. In every Linux distro I've tried I've had apps just up and die, but nothing is perfect. Maybe this is all some developer mumbo-jumbo thats super important, but it seems pretty small to me especially since you haven't experienced this doomsday you speak of. In fact I've never heard of anyone having a problem, caused by pulseaudio, like what you describe. I'll keep my eyes on what happens with fedora 8, but you may want to put the gun down for now.

    Also, I don't think pulseaudio is suppose to replace ALSA... I don't even think it can, were you talking about the ALSA dmix plugin?
    It wouldn't cause a problem if you have enough memory. The only problem a malloc error like this would cause is that it's unable to deal with the inability to allocate MORE memory.

    If YOUR program catches it and tells the user that it can't allocate more memory, then all may be well. But, if the library bails on its own, then you have no ability to save the users data and report the error... It just closes.

    YOU may not see this error, but people with low memory would. And if an error occurs... Oops. There goes your data!!!

  8. #18
    Join Date
    Jan 2006
    Location
    Philadelphia
    Beans
    4,066
    Distro
    Ubuntu 8.10 Intrepid Ibex

    Re: How NOT to write a shared library

    Quote Originally Posted by j_g View Post
    I posted my objection in a forum here that is supposed to be specifically for providing the Ubuntu developers "feedback" about what features to add to Ubuntu.
    well, that's where you are missing some key info. this "programming talk" forum is NOT for ubuntu developers (i.e. people who make ubuntu), but for developers who happen to be using ubuntu. in other words, there no guarantee that you'll catch the eye of any actual ubuntu developers by posting here. as suggested in other posts, you'd do much better by posting a launchpad bug - or even a launchpad question, if you don't think this qualifies as a "bug" per se.

  9. #19
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    Quote Originally Posted by hanzomon4 View Post
    Has anyone had a program vanish while using pulseaudio because of this "problem"?
    First of all, as Wy rightfully points out, the problem would most likely be manifested in low memory conditions, because the exit() is used in a function to handle memory allocation failure. If you've not encountered a low memory condition, then you likely would not have seen any manifestation of this design flaw.

    On the other hand, exit() may have been used in other places in Pulse Audio, and so there may be other conditions (besides low memory) when it could cause instability and unusability. I haven't looked at all the Pulse Audio source code. Within 5 mins of visiting the home page, I ran across this description of pa_malloc() and immediately red flags went off when I read that it can terminate an app by design. Further investigation shows that it does indeed call exit(). I noticed a couple other Pulse Audio functions also call pa_malloc(). Before anyone adds this code to a distro, a serious "security audit" of all the code should be made. There are security and stability issues with it. I'm frankly surprised that Fedora went with it as is.

    Will it terminate an app without warning or a chance for data preservation? Absolutely. exit() (and Pulse Audio's use of it) provides no means of notification nor data preservation. The whole purpose of exit() is to terminate an app right then and there.

    So, you wouldn't know that it was pulse audio causing any unusual behavior on your system (unless you're running a debug version of the code, and run all your apps from the command line). And remember that not all apps have a user interface, so it's not even that you may see a window disappear. (When I say "app", I mean any non-kernel code -- that is to say, any code not running at ring 0). You may see aberrant behavior that happens for what would appear to be "no reason" to an enduser. Note that Pulse Audio also includes a daemon which may or may not be vulnerable as a result of calling (directly or indirectly) pa_malloc. As an enduser, you wouldn't "see" this daemon go down abruptly. A daemon has no user interface. You simply may notice something weird happening on your system, or something suddenly no longer working.

    it seems pretty small to me especially since you haven't experienced this doomsday you speak of.
    Well, I certainly haven't experienced any instability or unusabiliy due to Pulse Audio, because I don't use it on my systems. And I won't be installing it either (not unless a full security audit is done, and these design flaws are fixed).

    I also wouldn't expect an enduser to worry about the details of software implementation. That is not something that an enduser should have to deal with at all. But I can assure you that pa_malloc() and any Pulse Audio function that directly or indirectly calls it has the potential to abruptly terminate an app. Just because no one has yet confirmed that this design flaw in Pulse Audio specifically has been responsible for some aberrant behavior doesn't mean that it won't happen (or even that it hasn't happened already. I know that this thing has only recently been put into major use, so it's not likely that we've yet to see people able to identify increased instability due to this software specifically. But it's not like your system is going to let you know that Pulse Audio caused something to stop working. It's a plain call to exit(). User mode just disappears, with whatever consequences that engenders. Has anyone observed something on Fedora suddenly not working as it should - particularly anything that may utilize the sound system?).

    I don't think pulseaudio is suppose to replace ALSA.
    I don't know if any kernel folks are planning to eventually deprecate ALSA, and replace it with Pulse Audio. (But I worry that this could be a potential threat. Fedora is already putting it in their distro, and it looks like Suse and Ubuntu are seriously considering it).

    But what is true right now is that Pulse Audio sits between an ALSA app and the hardware, and also various other audio APIs and the hardware. If all this user mode code is now suddenly being redirected (without even the code's knowledge) through Pulse Audio, then it all inherits the consequences of Pulse Audio's design.

    Hopefully, any kernel developers considering it for inclusion will do a security audit, and see this design flaw. Hopefully, distro providers will do the same. (Again, I'm really surprised the Fedora guys missed it. I would have expected them to be more cautious about stability than other distros).
    Last edited by j_g; November 15th, 2007 at 08:59 AM.

  10. #20
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    Quote Originally Posted by nanotube View Post
    this "programming talk" forum is NOT for ubuntu developers (i.e. people who make ubuntu)
    It wasn't in this forum that I posted a message saying that I didn't think Pulse Audio should be included in an upcoming Ubuntu (and linked to this thread for details about my objection). It was a forum here (ie, on this web site) that is purported to be a place where people (ie endusers) provide opinions to the Ubuntu developers as to what should (and persumably shouldn't) be added to Ubuntu.

Page 2 of 10 FirstFirst 1234 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •