Bug 16500 - Rscript doesn't seem to like SIGPIPE and core dumps
Summary: Rscript doesn't seem to like SIGPIPE and core dumps
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: I/O (show other bugs)
Version: R 3.2.0
Hardware: x86_64/x64/amd64 (64-bit) Linux
: P5 normal
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2015-08-07 02:30 UTC by Benjamin Tyner
Modified: 2015-12-14 13:48 UTC (History)
1 user (show)

See Also:


Attachments
test case (55 bytes, text/plain)
2015-08-07 02:30 UTC, Benjamin Tyner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Tyner 2015-08-07 02:30:06 UTC
Created attachment 1878 [details]
test case

If I run the attached from the command line through Rscript thusly:

   > Rscript ./pipe.R | head

then I get:

   Error: ignoring SIGPIPE signal
   Execution halted
   *** Error in `/usr/lib/R/bin/exec/R': double free or corruption (!prev): 0x0000000000d1f000 ***
   Aborted (core dumped)

What is the best way to approach this? It's not clear (to me) how to run Rscript through valgrind or gdb.
Comment 1 Benjamin Tyner 2015-08-07 13:09:15 UTC
Figured out how to trigger through valgrind; under R 3.2.1,

   > R --no-save -d valgrind -e "write.table(iris, file = pipe('head', open = 'w'))"

gave:

==13901== Invalid read of size 4                                   
==13901==    at 0x38B9866384: fclose@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==13901==    by 0x4E0AD75: Rstd_CleanUp (sys-std.c:1104)                  
==13901==    by 0x4D4D530: do_quit (main.c:1262)                          
==13901==    by 0x4D1B589: bcEval (eval.c:5490)                           
==13901==    by 0x4D269AF: Rf_eval (eval.c:558)                           
==13901==    by 0x4D280DE: Rf_applyClosure (eval.c:1039)                  
==13901==    by 0x4D26B2E: Rf_eval (eval.c:674)                           
==13901==    by 0x4D26D52: Rf_eval (eval.c:627)                           
==13901==    by 0x4D290D1: do_begin (eval.c:1716)                         
==13901==    by 0x4D26D52: Rf_eval (eval.c:627)                           
==13901==    by 0x4D280DE: Rf_applyClosure (eval.c:1039)                  
==13901==    by 0x4D26B2E: Rf_eval (eval.c:674)                           
==13901==  Address 0x65091c0 is 0 bytes inside a block of size 568 free'd 
==13901==    at 0x4A063F0: free (vg_replace_malloc.c:446)                 
==13901==    by 0x38B98664CC: fclose@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==13901==    by 0x4E0AD75: Rstd_CleanUp (sys-std.c:1104)                  
==13901==    by 0x4D4E13F: run_Rmainloop (main.c:996)                     
==13901==    by 0x40084A: main (Rmain.c:29)                               

(and so on)
Comment 2 Brian Ripley 2015-08-12 11:31:16 UTC
I guess the '>' here is meant to be a shell prompt?

On a Unix-alike Rscript is just a small wrapper calling R.  So the problem is from the R executable called by the R front-end script.

The issue is that Rstd_cleanup is sometimes being called twice, which is due to the asynchronous nature of signal handlers.  I have added code to ensure that this fclose is only called once.

Fixed in R-devel and, soon, in 3.2.2 patched.
Comment 3 Benjamin Tyner 2015-08-12 22:12:42 UTC
Thank you Brian.

Yes, a shell prompt. If this is undesirable in bug reports, or if a different string for the prompt is preferred, I am more than happy to keep that in mind for future reports.
Comment 4 Peter Dalgaard 2015-08-12 22:25:17 UTC
(In reply to Benjamin Tyner from comment #3)
> Thank you Brian.
> 
> Yes, a shell prompt. If this is undesirable in bug reports, or if a
> different string for the prompt is preferred, I am more than happy to keep
> that in mind for future reports.

Nah, it's just a slightly unusual choice and not really necessary in your examples.