[R] does segfault mean (always) a bug?

[Martin Maechler]

>>>>> lejeczek  <peljasz at yahoo.co.uk>
>>>>>     on Wed, 6 May 2015 08:20:46 +0100 writes:

    > On 05/05/15 20:36, Duncan Murdoch wrote:
    >> On 05/05/2015 2:54 PM, lejeczek wrote:
    >>> hi eveybody
    >>> 
    >>> I'm trying something simple (Biocunductor packages), so
    >>> simple I believe it's example from docs but I get segfault.
    >>> I don't suppose incorrect scripting can cause segfault, right?
    >> In R, a segfault always indicates a bug.  What's not so clear is whether
    >> it is a bug in R, a bug in a contributed package, or a bug in some
    >> underlying system library.
    >> 
    >> If you can only trigger the bug when using a Bioconductor package, then
    >> the first guess is that it is that package, and the maintainer of that
    >> package is in the best position to track it down further.  If you can
    >> simplify the code to trigger it without using any contributed packages,
    >> then it could well be a bug in R, and we'd like to see code to reproduce it.
    >> 
    >> Duncan Murdoch
    >> 
    > hi Duncan
    > I remember that this was a principle of most of programming 
    > languages, only a bug in the code and/or compiler could 
    > cause segfault.
    > In my case it is a contributed package, specifically GOSim 
    > package, I'm not R programmer and I realise my scripting is 
    > far from good and possibly with errors.
    > I could send that snippet of the code here if people think 
    > it can be looked into and segfault could be replicated?
    > I also emailed the author.

    > many thanks
    > P.

Dear P.,

in the case of segfault from using a contributed package,
you should typically really only email the package maintainer
(which may different than the package authors), and not R-help.
Only if the maintainer does not respond at all (and only if the
package is open source, typically CRAN) should you ask for help here
or another public forum.

(I would also think it to be polite to the maintainer who has
 volunteered her/his code to be used by you if you give him an
 opportunity to see, comment and fix the problem)

Martin Maechler
ETH Zurich