bugGNU Octave - Bugs: bug #52118, randg: missing documentation for...

 
 

bug #52118: randg: missing documentation for first argument A

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Tue 26 Sep 2017 10:21:01 AM UTC
   
 
Category:  Octave Function Severity:  4 - Important
Priority:  5 - Normal Item Group:  Documentation
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 26 Sep 2017 10:19:33 PM UTC, comment #5: 

I checked in a change for the documentation on the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/a6cf8e06603a).  The change was also merged on to default.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Tue 26 Sep 2017 06:56:15 PM UTC, comment #4: 

Yes I agree with all comment  #3: the SIGSEGV looks like a false positive due the presence of the address sanitizer. The following also triggers the same SIGSEGV:


a = zeros (1e6);


Only does the documentation have to be updated. Updating the title and the category of this report.

Pantxo Diribarne <pantxo>
Group Member
Tue 26 Sep 2017 05:28:35 PM UTC, comment #3: 

Looking more closely, it does seem that the documentation needs to be fixed.  The calling form for two inputs is really


randg (A, N)


rather than


randg (M, N)


as would be expected from the other randXXX functions and the documentation.  Hence, when called with


randg (1, 1e6)


the function is trying to create a 1e6 X 1e6 matrix which is quite large.

My first thought is that the documentation needs to be updated to be like that of randp which does properly document the first argument.

The second issue, the segfault, might just be a problem with the Address Sanitizer.  I get a segfault when I execute


x = zeros (1e6);


But when I run a version of Octave that hasn't been compiled with the Address Sanitizer then I get


x = zeros (1e6)
error: out of memory or dimension too large for Octave's index type


This seems correct.  The top of the backtrace log for me contains


==7785==WARNING: AddressSanitizer failed to allocate 0x0746a5288000 bytes
==7785==AddressSanitizer's allocator is terminating the process instead of returning 0
==7785==If you don't like this behavior set allocator_may_return_null=1


I tried setting the variable suggested to control AddressSanitizer, and now I get a slightly different backtrace.  However, my guess is that when compiled normally Octave just gets this right.  The call to new() is too large and the library throws an exception which Octave then catches and returns an error message.



Rik <rik5>
Group administrator
Tue 26 Sep 2017 05:11:14 PM UTC, comment #2: 

There appears to be something wrong with the input validation for randg.  Interestingly, if you look at the various randXXX functions, they all call do_rand to do the work.  The prototype for do_rand is


do_rand (const octave_value_list& args, int nargin, const char *fcn,
         const std::string& distribution, bool additional_arg = false)


Notice that additional_arg is usually false.  The only functions which call do_rand with this argument set to true are randg and randp.  So I tried


randp (1, 1e6)


and this segfaults as well.

So it looks like the input additional_arg is the proximate cause, but it still needs to be tracked down why it is causing a problem.

Rik <rik5>
Group administrator
Tue 26 Sep 2017 04:47:55 PM UTC, comment #1: 

Confirmed.  Even if the inputs are invalid, Octave should not segfault.  Here is a longer backtrace from the Address Santizer.


==21650==WARNING: AddressSanitizer failed to allocate 0x0746a5288000 bytes
==21650==AddressSanitizer's allocator is terminating the process instead of returning 0
==21650==If you don't like this behavior set allocator_may_return_null=1
==21650==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator.cc:147 "((0)) != (0)" (0x0, 0x0)
    #0 0x7fe37dc73631  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa0631)
    #1 0x7fe37dc78613 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa5613)
    #2 0x7fe37dbf0425  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x1d425)
    #3 0x7fe37dc76865  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa3865)
    #4 0x7fe37dbf5b4d  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x22b4d)
    #5 0x7fe37dc6c67e in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9967e)
    #6 0x7fe37c5c3f96 in Array<double>::ArrayRep::ArrayRep(long) liboctave/array/Array.h:159
    #7 0x7fe37ab2fd11 in Array<double>::clear(dim_vector const&) (/home/rik/wip/Projects_Mine/octave-dbg/liboctave/.libs/liboctave.so.4+0x594d11)
    #8 0x7fe37b36c144 in octave_rand::do_nd_array(dim_vector const&, double) liboctave/numeric/oct-rand.cc:513
    #9 0x7fe37d3392d6 in octave_rand::nd_array(dim_vector const&, double) liboctave/numeric/oct-rand.h:169
    #10 0x7fe37d336ebe in do_rand libinterp/corefcn/rand.cc:306
    #11 0x7fe37d337c43 in Frandg(octave_value_list const&, int) libinterp/corefcn/rand.cc:747
    #12 0x7fe37c9c5fc6 in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) libinterp/octave-value/ov-builtin.cc:65
    #13 0x7fe37ccbbd4b in octave::tree_evaluator::visit_index_expression(octave::tree_index_expression&) libinterp/parse-tree/pt-eval.cc:1252
    #14 0x7fe37cceecc0 in octave::tree_index_expression::accept(octave::tree_walker&) libinterp/parse-tree/pt-idx.h:101
    #15 0x7fe37ca46a7a in octave::tree_evaluator::evaluate(octave::tree_expression*, int) libinterp/parse-tree/pt-eval.h:271
    #16 0x7fe37ccc151e in octave::tree_evaluator::visit_simple_assignment(octave::tree_simple_assignment&) libinterp/parse-tree/pt-eval.cc:2087
    #17 0x7fe37cca6cfc in octave::tree_simple_assignment::accept(octave::tree_walker&) libinterp/parse-tree/pt-assign.h:83
    #18 0x7fe37ca46a7a in octave::tree_evaluator::evaluate(octave::tree_expression*, int) libinterp/parse-tree/pt-eval.h:271
    #19 0x7fe37ccc2438 in octave::tree_evaluator::visit_statement(octave::tree_statement&) libinterp/parse-tree/pt-eval.cc:2211
    #20 0x7fe37cd00412 in octave::tree_statement::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:112
    #21 0x7fe37ccc2753 in octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) libinterp/parse-tree/pt-eval.cc:2253
    #22 0x7fe37ca47318 in octave::tree_statement_list::accept(octave::tree_walker&) libinterp/parse-tree/pt-stmt.h:187
    #23 0x7fe37d14f47a in octave::interpreter::main_loop() libinterp/corefcn/interpreter.cc:974
    #24 0x7fe37d14d30d in octave::interpreter::execute() libinterp/corefcn/interpreter.cc:695
    #25 0x7fe37c49ae8b in octave::cli_application::execute() libinterp/octave.cc:384
    #26 0x401d7c in main src/main-cli.cc:90
    #27 0x7fe379c5982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #28 0x401808 in _start (/home/rik/wip/Projects_Mine/octave-dbg/src/.libs/lt-octave-cli+0x401808)



Rik <rik5>
Group administrator
Tue 26 Sep 2017 10:21:01 AM UTC, original submission:  

The documentation for randg mentions the "A" argument but it is not mentioned in the list of call forms. So far this is a documentation bug.

Now if you try to call randg as you would call other rand* functions, e.g.


a = randg (1,1e6);


You'll get either "out of memory or dimension too large for Octave's index type" in Octave 4.2, or


==7981== WARNING: AddressSanitizer failed to allocate 0x0012a05f2000 bytes
ASAN:SIGSEGV
=================================================================
==7981== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb4cfa76beb sp 0x7fb4b3761830 bp 0x7fb4b3761a60 T1)
AddressSanitizer can not provide additional info.


with the current dev. and the address sanitizer enabled. For some reason I can't get any useful backtrace.

Pantxo Diribarne <pantxo>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-09-26 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2017-09-26 pantxo Item GroupSegfault, Bus Error, etc. Documentation
        Summaryrandg: segfault with erroneous arguments randg: missing documentation for first argument A
    2017-09-26 rik5 Severity3 - Normal 4 - Important
    2017-09-26 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code