Hi Roger, Cecilio,
For what it's worth, we have faced this in Mixxx:
https://bugs.launchpad.net/mixxx/+bug/1097286
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765375
Users perceive it as a "crash" when the distro has chosen to build PortMIDI
with PM_CHECK_ERRORS defined. It took a while but we finally got it fixed
in Debian. Other distros may have the issue -- we only really care about
Debian derivatives. For Windows/Mac we build PortMIDI ourselves so it
doesn't affect us.
We struggle with this question ourselves and we recently added a
"DEBUG_ASSERTS_ARE_FATAL" flag that is opt-in so that even confused users
or distro maintainers who build Mixxx in debug mode don't end up triggering
debug asserts and ruining someone's party. We redefined our debug assert
macro to be
DEBUG_ASSERT_AND_HANDLE(condition) {
// Graceful error handling code for when debug asserts are not fatal or
in release mode.
}
To strongly hint that developers should pair every assert with code to
gracefully (i.e. not segfault) handle the assertion.
Cheers,
RJ
On Thu, Jan 8, 2015 at 9:51 AM, cecilio <[email protected]> wrote:
> Hi,
> Thank you Roger, but the problem is there anyway.
>
> Linking statically is a partial solution as it only solves the issue for
> those who install binary packages. And although you state that "...it is
> for debugging and developing simple apps, it should never be on in a system
> installation." the fact is that in some distros (at least Ubuntu and Linux
> Mint) the library is distributed with PM_CHECK_ERRORS defined. This
> suggests that people building the packages for these distros are not aware
> of the purpose and consequences of defining this macro.
>
> Something should be done. I propose several alternatives:
>
> a) Deactivate this macro if not a debug build (that is, requiring that
> macro DEBUG is also defined, i.e replacing line 48 in portmidi.c by::
>
> #if defined(DEBUG) && defined (PM_CHECK_ERRORS)
>
> b) Changing the macro name. i.e. PM_CHECK_ERRORS --> PM_DEBUG_CHECK_ERRORS
> to emphasize that it should be only defined in debug builds.
>
> c) Improve documentation oriented to distro maintainers
>
> d) The initial one: transform this option into a runtime option.
>
> Best regards,
> Cecilio
>
>
>
> 2015-01-08 13:45 GMT+01:00 Roger Dannenberg <[email protected]>:
>
>> Hi Cecilio,
>> PM_CHECK_ERRORS is for debugging and writing simple apps where you'd
>> rather crash with a sane error message to the console than fail silently.
>> Since it is for debugging and developing simple apps, it should never be on
>> in a system installation.
>> Portmidi is pretty small -- I think you could save a lot of headaches
>> by linking statically. Then you get exactly what you want and eliminate the
>> need to install a dynamic library.
>> -Roger
>>
>>
>> On 1/5/15 5:42 PM, cecilio wrote:
>>
>> Hi Roger,
>>
>> I'm facing a frustrating issue related to portmidi error reporting. It
>> seems that there are two alternatives:
>>
>> 1. print an error message to stdio and abort program execution, or
>> 2. return an error code.
>>
>> In my app I would like to use the second option (handle all errors, so I
>> would expect portmidi returning an error code/message) but the issue is
>> that this is not a portmidi runtime option but a portmidi build time
>> option, controlled by macro PM_CHECK_ERRORS. Therefore, *all* applications
>> are forced to use the reporting option chosen by sysadmins (or by distro
>> package builders, Linux Mint in may case).
>>
>> Moreover I can not distribute an application behaving consistently from
>> one machine to another as a portmidi error (i.e. buffer overflow) would
>> generate a crash in some machines but in others the app. will be able to
>> handle the error, depending on the installed portmidi library.
>>
>> Probably I'm missing something but, if not, I would suggest to change the
>> code to facilitate applications to choose the desired behaviour instead of
>> being something determined by sysadmins when installing the portmidi
>> library or by the distro portmidi package. Perhaps to have a run time
>> option for setting the error reporting behaviour or to throw an exception
>> instead of the 'exit(-1);' instruction, so that an application can opt for
>> catching the exception or ignoring it and crashing. Could this be feasible?
>>
>> Thank you very much,
>> Cecilio Salmeron
>>
>>
>> _______________________________________________
>> media_api mailing
>> [email protected]http://lists.create.ucsb.edu/mailman/listinfo/media_api
>>
>>
>> _______________________________________________
>> media_api mailing list
>> [email protected]
>> http://lists.create.ucsb.edu/mailman/listinfo/media_api
>>
>>
>
> _______________________________________________
> media_api mailing list
> [email protected]
> http://lists.create.ucsb.edu/mailman/listinfo/media_api
>
>
_______________________________________________
media_api mailing list
[email protected]
http://lists.create.ucsb.edu/mailman/listinfo/media_api
