bugGNU Octave - Bugs: bug #55046, Add static compile-time checking...

 
 

bug #55046: Add static compile-time checking of printf functions using compiler attributes

Submitter:  Kai Torben Ohlhus <siko1056>
Submitted:  Sat 17 Nov 2018 11:15:57 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 04 Dec 2018 10:19:57 PM UTC, comment #29: 

Finally I can confirm, that the cset of comment #27 by you Markus fixes all warnings for me.

The macro "OCTAVE_FORMAT_PRINTF" is a bit less general than my previous version, but as you might think too, there are rare scenarios imaginable where you need other function prototypes than _printf_.

Then I think all work is done, right?

Kai Torben Ohlhus <siko1056>
Group Member
Tue 04 Dec 2018 08:41:33 AM UTC, comment #28: 

I am still very interested in your patch and try it later today on openSUSE 15 and report back ;-)

Kai Torben Ohlhus <siko1056>
Group Member
Tue 04 Dec 2018 08:33:45 AM UTC, comment #27: 

I checked in some changes that should mute the compiler warnings about mis-matching format specifier.
In the last changeset [1], I had to change the new attribute for MinGW. Fortunately, other projects already had to solve the same problem. The new logic is more or less the same approach Mozilla took [2].

At the moment I cannot reach the buildbot interface. Therefore, I don't know how the changes behave on other systems than mine.

Re-opening as ready for test.

[1]: https://hg.savannah.gnu.org/hgweb/octave/rev/7f6a50f73625
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1331349

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Nov 2018 07:09:05 PM UTC, comment #26: 

The attached patch is a proof of concept that could be used in format strings for formatting octave_idx_type.

It looks a bit verbose. But if I understand correctly, the current syntax isn't strictly correct either. We could be displaying wrong values in the string if the value of the octave_idx_type is larger than INT_MAX.

And it avoids the compiler warnings. :-)

Any thoughts?

(file #45561)

Markus Mützel <mmuetzel>
Group administrator
Thu 29 Nov 2018 09:58:12 PM UTC, comment #25: 

I think jwe might have solved a similar problem relatively recently using the macro approach.  The exact details have slipped my mind.

Rik <rik5>
Group administrator
Thu 29 Nov 2018 09:57:00 PM UTC, comment #24: 

Another possibility is to define a macro that is either "%" PRId64 or "%" PRId32 depending on what we use for octave_idx_type.

Markus Mützel <mmuetzel>
Group administrator
Thu 29 Nov 2018 09:49:47 PM UTC, comment #23: 

For the octave_idx_type we could maybe static_cast to "int64_t" and use '"%" PRId64' as format identifier. See e.g. [1].

Alternatively, "long long int" and "%lld" should be large enough on all platforms.

Is there any penalty for using static_cast? (Apart from the code becoming more cluttered.)

[1]: https://en.cppreference.com/w/cpp/types/integer

Markus Mützel <mmuetzel>
Group administrator
Thu 29 Nov 2018 08:51:16 PM UTC, comment #22: 

The "%s" requirement is totally reasonable to me as well.  I am a bit surprised that my system does not compile with "-Wformat-security" by default.  Thus I made no effort to silence those warnings.  Thanks for comment #21 Rik.

The good news: on Octave language level this doesn't matter after all for this short form of using error() is valid.

Users/developers that work on C/C++-level with Octave should know how to handle this warning (after some googleing) or switch back to the save Octave level.

When compiling the simple example below with "-Wformat-security" we'll receive this warning as well:


#include <cstdio>

int main () {
  char str[] = "Hi";
  char * ptr = str;
  std::printf (ptr);
  return 0;
}


To me it is the nature of C and we should not try hide this at the price of more complexity (=pain for the future).

And Rik you are right.  The pain of comment #18 is not really an acceptable option.  Maybe we should use the "real" definition of the macro "OCTAVE_FORMAT_ATTRIBUTE" when, for example, the "sanitizer" flags are given at configure time?

Kai Torben Ohlhus <siko1056>
Group Member
Thu 29 Nov 2018 08:16:40 PM UTC, comment #21: 

Good point.  It was an easy enough change so I did that here (https://hg.savannah.gnu.org/hgweb/octave/rev/242aa7b2c783).

Still need a reasonable solution for the differently sized integers.

Rik <rik5>
Group administrator
Thu 29 Nov 2018 07:38:05 PM UTC, comment #20: 

Introducing the "%s" might not be such a bad idea after all.
If for some reason err_msg contained a format specifier, unexpected things might happen.

Markus Mützel <mmuetzel>
Group administrator
Thu 29 Nov 2018 05:21:00 PM UTC, comment #19: 

Checking out the errors related to strings, I find this


libinterp/dldfcn/symbfact.cc:380:28: warning: format not a string literal and no format arguments [-Wformat-security]


And the code for that is


  if (! err_msg.empty ())
    error (err_msg.c_str ());


This seems like valid syntax to me.  I can shut up the error by using


    error ("%s", err_msg.c_str ());


but this seems unnecessary.

In error.h the prototype for the error function is


OCTAVE_FORMAT_ATTRIBUTE (__printf__, 1, 2)
OCTAVE_NORETURN OCTINTERP_API extern
void error (const char *fmt, ...);


Do we need a second prototype (and implementation in error.cc) that accepts just a string and has no OCTAVE_FORMAT_ATTRIBUTE declaration.

For example,


OCTAVE_NORETURN OCTINTERP_API extern
void error (const char *str);


It doesn't really work because the compiler can't distinguish between the two two prototypes


libinterp/corefcn/error.cc:1957:61: error: call of overloaded ‘error(const char [40])’ is ambiguous
             error ("lasterror: unrecognized string argument");
                                                             ^
libinterp/corefcn/error.cc:575:1: note: candidate: void error(const char*, ...)
 error (const char *fmt, ...)
 ^~~~~
libinterp/corefcn/error.cc:568:1: note: candidate: void error(const char*)
 error (const char *str)


I suppose we could change the prototype


void
error (const char *fmt, ...)
{
  va_list args;
  va_start (args, fmt);
  verror (fmt, args);
  va_end (args);
}


to


void
error (const char *fmt, arg1, ...)
{
  va_list args;
  va_start (arg1, args, fmt);
  verror (fmt, args);
  va_end (args);
}


Maybe at that point it is better to just introduce the format string "%s".

Thoughts?


Rik <rik5>
Group administrator
Thu 29 Nov 2018 04:46:22 PM UTC, comment #18: 

I think there is a bit more work cleaning up the new warnings that have been generated.

When compiling I now get these warning (also attached as a file)


libinterp/dldfcn/__eigs__.cc:606:79: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/__eigs__.cc:610:30: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/__eigs__.cc:610:30: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/convhulln.cc:256:66: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
         warning ("convhulln: facet %d only has %d vertices", i, j);
libinterp/dldfcn/convhulln.cc:256:66: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/qr.cc:331:70: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/qr.cc:331:70: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/qr.cc:347:70: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/qr.cc:347:70: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/dldfcn/symbfact.cc:380:28: warning: format not a string literal and no format arguments [-Wformat-security]
libgui/graphics/Table.cc:312:45: warning: format not a string literal and no format arguments [-Wformat-security]
         warning (warn_string.str ().c_str ());
libgui/graphics/Table.cc:554:46: warning: format not a string literal and no format arguments [-Wformat-security]
       warning (error.string_value ().c_str ());
libinterp/octave-value/ov-java.cc:1941:30: warning: format not a string literal and no format arguments [-Wformat-security]
libinterp/parse-tree/oct-parse.yy:5688:52: warning: format not a string literal and no format arguments [-Wformat-security]
libinterp/parse-tree/pt-eval.cc:2399:37: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/parse-tree/pt-eval.cc:2426:79: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/parse-tree/pt-eval.cc:2723:53: warning: format not a string literal and no format arguments [-Wformat-security]
libinterp/parse-tree/pt-eval.cc:3488:45: warning: format not a string literal and no format arguments [-Wformat-security]
libinterp/corefcn/__magick_read__.cc:881:38: warning: format ‘%i’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=]
libinterp/corefcn/__magick_read__.cc:914:21: warning: format ‘%i’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/cellfun.cc:1881:74: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/cellfun.cc:1881:74: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/data.cc:2734:71: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/data.cc:5480:27: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/errwarn.cc:102:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/errwarn.cc:102:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/errwarn.cc:102:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/errwarn.cc:102:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/ft-text-renderer.cc:73:83: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘FT_ULong {aka long unsigned int}’ [-Wformat=]
libinterp/corefcn/ft-text-renderer.cc:80:83: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘FT_ULong {aka long unsigned int}’ [-Wformat=]
libinterp/corefcn/graphics.cc:2459:46: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/graphics.cc:2459:46: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/graphics.cc:12120:63: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/graphics.cc:12120:63: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/hex2num.cc:71:67: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
libinterp/corefcn/ls-mat-ascii.cc:332:33: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/ls-oct-text.cc:378:52: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
         warning ("ignoring last %d columns", extras);
libinterp/corefcn/mex.cc:2184:35: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
libinterp/corefcn/oct-stream.cc:2661:37: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
libinterp/corefcn/sub2ind.cc:134:51: warning: format not a string literal and no format arguments [-Wformat-security]
libinterp/corefcn/syscalls.cc:293:24: warning: format not a string literal and no format arguments [-Wformat-security]


I'll take care of the "format not a string literal", but that leaves a large number of int warnings.  We need a general strategy about those.  I suspect the issues is that a lot of them are octave_idx_type which can be either 32-bit (int) or 64-bit (long int).  It would be a pain to have to replicate every warning or error and have an #ifdef to decide based on the size of octave_idx_type.


(file #45552)

Rik <rik5>
Group administrator
Thu 29 Nov 2018 12:55:58 PM UTC, comment #17: 

Finally I made progress here http://hg.savannah.gnu.org/hgweb/octave/rev/216d857732eb.  My problem was like so often, that I was working at the "wrong" place.  There are indeed two spots, where macros like "OCTAVE_NORETURN" are defined.  Those are:


build-aux/mk-octave-config-h.sh
oct-conf-post.in.h


Maybe one can avoid this duplication?

After adding the new macro "OCTAVE_FORMAT_ATTRIBUTE" to both, everything worked as expected and I could detect more warnings, that might lead to bad errors: http://hg.savannah.gnu.org/hgweb/octave/rev/8c72f0345ee8

I think we can now close this report.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 23 Nov 2018 01:03:52 PM UTC, comment #16: 

I started to work on this one, but got stuck with the macro expansion (see file #45515).

The Problem is in "libinterp/corefcn/error.h".  This version without the macro works:


__attribute__ ((__format__(__printf__, 1, 2)))
OCTAVE_NORETURN OCTINTERP_API extern
void error (const char *fmt, ...);


While this does not:


OCTAVE_FORMAT_ATTRIBUTE (__printf__, 1, 2)
OCTAVE_NORETURN OCTINTERP_API extern
void error (const char *fmt, ...);


with the error:


libinterp/corefcn/error.h:64:25: error: expected constructor, destructor, or type conversion before ‘(’ token
 OCTAVE_FORMAT_ATTRIBUTE (__printf__, 1, 2)
                         ^


I tried to use another working macro like "OCTAVE_DEPRECATED" declared in the very same file, but no luck either... any clue what I am doing wrong?! :(

Kai Torben Ohlhus <siko1056>
Group Member
Wed 21 Nov 2018 08:15:15 PM UTC, comment #15: 

Thanks for the fixes (comment #12 and comment #14) Rik, now the title covers exactly what should be done to avoid such errors in the future.

I like the idea of jwe (comment #11) that hides the compiler-detection clutter to a well defined place.  Do you want to work on this Rik or jwe?  Otherwise I can put it on my "deferred todo list" ^^

Kai Torben Ohlhus <siko1056>
Group Member
Wed 21 Nov 2018 06:19:07 PM UTC, comment #14: 

I pushed fixes for the other problem instances you found.  See https://hg.savannah.gnu.org/hgweb/octave/rev/05dfcb24ef12.

Rik <rik5>
Group administrator
Wed 21 Nov 2018 05:59:06 PM UTC, comment #13: 

I think it would be a good idea to catch these issues at compile time.

Expanding on what jwe said, there are already three examples of using compiler attributes in octave-config.h.  See OCTAVE_DEPRECATED, OCTAVE_NORETURN, OCTAVE_UNUSED.

The file octave-config.h is generated by the file build-aux/mk-octave-config-h.sh.  That is where the macro needs to be added.


Rik <rik5>
Group administrator
Wed 21 Nov 2018 05:54:16 PM UTC, comment #12: 

@Kai: I pushed the changeset to fix this segfault here: https://hg.savannah.gnu.org/hgweb/octave/rev/0cebf81fcdc5.

Rik <rik5>
Group administrator
Wed 21 Nov 2018 03:13:24 PM UTC, comment #11: 

I think adding attributes for these functions would be good.

It would also be good to do it in a way that is consistent with what we do for other attributes (see the generated octave-config.h file).  That way the conditionals checking for GCC are hidden in a header file.  If we conditionally define a macro like


OCTAVE_FORMAT_ATTRIBUTE (TYPE, INDEX, FIRST)


then we can just use that as needed and it can be defined for any compiler that supports this type of attribute feature.

John W. Eaton <jwe>
Group administrator
Wed 21 Nov 2018 08:41:21 AM UTC, comment #10: 

Using the technique of comment #9, I discovered other spots like that found by Rik:


libinterp/corefcn/graphics.h:1331:47: warning: format ‘%s’ expects a matching ‘char*’ argument [-Wformat=]
       error ("%s: property has no radio value");

libinterp/parse-tree/bp-table.cc:335:70: warning: format ‘%s’ expects a matching ‘char*’ argument [-Wformat=]
               error ("%s: line number must come before 'if' clause\n");
                                                                      ^
libinterp/parse-tree/bp-table.cc:349:70: warning: format ‘%s’ expects a matching ‘char*’ argument [-Wformat=]
               error ("%s: line number must come before 'if' clause\n");
                                                                      ^
libinterp/parse-tree/bp-table.cc:372:57: warning: format ‘%s’ expects a matching ‘char*’ argument [-Wformat=]
                          args(pos).type_name ().c_str ());
                                                         ^

libinterp/corefcn/data.cc:622:46: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘const char*’ [-Wformat=]
                args(1).class_name ().c_str ());
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

libinterp/corefcn/data.cc: In function ‘octave_value_list Fmod(const octave_value_list&, int)’:
libinterp/corefcn/data.cc:801:46: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘const char*’ [-Wformat=]
                args(1).class_name ().c_str ());
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

libinterp/corefcn/variables.cc: In function ‘octave_value set_internal_variable(double&, const octave_value_list&, int, const char*, double, double)’:
libinterp/corefcn/variables.cc:701:62: warning: format ‘%s’ expects argument of type ‘char*’, but argument 2 has type ‘double’ [-Wformat=]
         error ("%s: argument must be greater than %g", minval);
                                                              ^
libinterp/corefcn/variables.cc:703:71: warning: format ‘%s’ expects argument of type ‘char*’, but argument 2 has type ‘double’ [-Wformat=]
         error ("%s: argument must be less than or equal to %g", maxval);
                                                                       ^


But also "noise" (or potential source of error) like


libinterp/parse-tree/pt-eval.cc:2306:37: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘octave_idx_type {aka long int}’ [-Wformat=]
                                  k+1);


Kai Torben Ohlhus <siko1056>
Group Member
Wed 21 Nov 2018 08:08:43 AM UTC, comment #9: 

Rik, great observation with that warning!  Your patch (file #45493) solves my issue, I can fully cope with a warning in this case and consider this item to be fixed.

I checked my build logs and did not find anything like


warning: format ‘%s’ expects type ‘char *’,


which is usually shown when compiling with "-Wformat".

That might be because the compiler has no information that calls to


extern OCTINTERP_API void warning (const char *fmt, ...);


from <octave/error.h> are eventually passed to "printf"-like functions.

To make Octave more robust against such things, I propose a simple solution for GCC:


#include <octave/oct.h>
#include <octave/error.h>

// Inspired by https://stackoverflow.com/questions/2223968/how-to-get-warnings-of-incorrect-string-formatting-c
void save_warning (const char *fmt, ...)
#if defined(__GNUC__) || defined(__GNUG__)
  __attribute__ ((__format__(printf, 1, 2)));
#endif

int main () {
  warning ("load-path: update failed for '%s', removing from path", 1.3);
  warning ("load-path: update failed for '%s', removing from path");
  save_warning ("load-path: update failed for '%s', removing from path", 1.3);
  save_warning ("load-path: update failed for '%s', removing from path");
  return 0;
}

void save_warning (const char *fmt, ...)
{
  va_list args;
  va_start (args, fmt);
  warning (fmt, args);
  va_end (args);
}


Compile with


mkoctfile -Wformat -o main.exe main.cc


This means, that we only have to extend the definition of "warning" and "error" in "error.h" by a small GCC macro and we can get static compile time checking for free! =)

Any thoughts?

Kai Torben Ohlhus <siko1056>
Group Member
Tue 20 Nov 2018 03:48:04 AM UTC, comment #8: 

Sorry for the trouble.  I'll try to take another look at this problem.

John W. Eaton <jwe>
Group administrator
Mon 19 Nov 2018 11:25:40 PM UTC, comment #7: 

The original cset which introduced the problem was this one


changeset:   25957:d8993fe43a64
user:        John W. Eaton <jwe@octave.org>
date:        Tue Oct 23 15:52:42 2018 -0400
summary:     remove nonexistent directories when updating loadpath


It doesn't seem to remove nonexistent directories though.

Rik <rik5>
Group administrator
Mon 19 Nov 2018 11:20:52 PM UTC, comment #6: 

Whoops.  The cset is attached now.

(file #45493)

Rik <rik5>
Group administrator
Mon 19 Nov 2018 10:47:18 PM UTC, comment #5: 

Do not see the attachment...

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 19 Nov 2018 10:32:56 PM UTC, comment #4: 

Try the attached patch.  The problem seems to be that we were calling


warning ("format string %s")


where we said we would be supplying a string in the format argument, but then didn't supply one.

Before I got


warning: load-path: update failed for '', removing from path
warning: called from
    somefunc at line 2 column 3
    start_crash at line 2 column 1


, but now I get


warning: load-path: update failed for 'folder1', removing from path
warning: called from
    somefunc at line 2 column 3
    start_crash at line 2 column 1


One additional issue is that "folder1" does not seem to actually be removed form the path.  This means I get the same warning message every time I return to the prompt.


Rik <rik5>
Group administrator
Mon 19 Nov 2018 06:06:48 PM UTC, comment #3: 

I got s segfault:


start_crash
warning: load_path: folder1: No such file or directory
warning: called from
    somefunc at line 2 column 3
    start_crash at line 2 column 1
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)


I got the following trace in the logs:


 Process 27878 (lt-octave-gui) of user 1001 dumped core.

                                                   Stack trace of thread 28012:
                                                   #0  0x00007fd9c979fc4a __GI___strlen_sse2 (libc.so.6)
                                                   #1  0x00007fd9c9755844 printf_positional (libc.so.6)
                                                   #2  0x00007fd9c9756796 vfprintf (libc.so.6)
                                                   #3  0x00007fd9c977f87d vasprintf (libc.so.6)
                                                   #4  0x00007fd9d0a8f0e8 _ZN6octave9vasprintfB5cxx11EPKcP13__va_list_tag (liboctinterp.so.6)
                                                   #5  0x00007fd9d0a8f154 _ZN6octave7vformatERSoPKcP13__va_list_tag (liboctinterp.so.6)
                                                   #6  0x00007fd9d07493c2 vwarning (liboctinterp.so.6)
                                                   #7  0x00007fd9d074c1a6 warning_1 (liboctinterp.so.6)
                                                   #8  0x00007fd9d074c6ec _Z7warningPKcz (liboctinterp.so.6)
                                                   #9  0x00007fd9d090756c _ZNK6octave9load_path6updateEv (liboctinterp.so.6)
                                                   #10 0x00007fd9d073158c octave_change_to_directory (liboctinterp.so.6)
                                                   #11 0x00007fd9d0731b25 _Z3FcdRK17octave_value_listi (liboctinterp.so.6)
                                                   #12 0x00007fd9d049ab00 _ZN14octave_builtin4callERN6octave14tree_evaluatorEiRK17octave_value_list (liboctinterp.so.6)
                                                   #13 0x00007fd9d061de5e _ZN6octave14tree_evaluator22visit_index_expressionERNS_21tree_index_expressionE (liboctinterp.so.6)
                                                   #14 0x00007fd9d04dafee _ZN6octave14tree_evaluator8evaluateEPNS_15tree_expressionEi (liboctinterp.so.6)
                                                   #15 0x00007fd9d0619769 _ZN6octave14tree_evaluator15visit_statementERNS_14tree_statementE (liboctinterp.so.6)
                                                   #16 0x00007fd9d060fd00 _ZN6octave14tree_statement6acceptERNS_11tree_walkerE (liboctinterp.so.6)
                                                   #17 0x00007fd9d061aacb _ZN6octave19tree_statement_list6acceptERNS_11tree_walkerE (liboctinterp.so.6)
                                                   #18 0x00007fd9d056b772 _ZN20octave_user_function4callERN6octave14tree_evaluatorEiRK17octave_value_list (liboctinterp.so.6)
                                                   #19 0x00007fd9d061de5e _ZN6octave14tree_evaluator22visit_index_expressionERNS_21tree_index_expressionE (liboctinterp.so.6)
                                                   #20 0x00007fd9d04dafee _ZN6octave14tree_evaluator8evaluateEPNS_15tree_expressionEi (liboctinterp.so.6)
                                                   #21 0x00007fd9d0619769 _ZN6octave14tree_evaluator15visit_statementERNS_14tree_statementE (liboctinterp.so.6)
                                                   #22 0x00007fd9d060fd00 _ZN6octave14tree_statement6acceptERNS_11tree_walkerE (liboctinterp.so.6)
                                                   #23 0x00007fd9d0613bdd _ZN6octave19tree_statement_list6acceptERNS_11tree_walkerE (liboctinterp.so.6)
                                                   #24 0x00007fd9d056b712 _ZN18octave_user_script4callERN6octave14tree_evaluatorEiRK17octave_value_list (liboctinterp.so.6)
                                                   #25 0x00007fd9d0612e71 _ZN6octave14tree_evaluator16visit_identifierERNS_15tree_identifierE (liboctinterp.so.6)
                                                   #26 0x00007fd9d04dafee _ZN6octave14tree_evaluator8evaluateEPNS_15tree_expressionEi (liboctinterp.so.6)
                                                   #27 0x00007fd9d0619769 _ZN6octave14tree_evaluator15visit_statementERNS_14tree_statementE (liboctinterp.so.6)
                                                   #28 0x00007fd9d060fd00 _ZN6octave14tree_statement6acceptERNS_11tree_walkerE (liboctinterp.so.6)
                                                   #29 0x00007fd9d0612a4b _ZN6octave19tree_statement_list6acceptERNS_11tree_walkerE (liboctinterp.so.6)
                                                   #30 0x00007fd9d08f468a _ZN6octave11interpreter7executeEv (liboctinterp.so.6)
                                                   #31 0x00007fd9d0f28310 _ZN6octave18octave_interpreter7executeEv (liboctgui.so.4)
                                                   #32 0x00007fd9ceb5e0f6 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5)
                                                   #33 0x00007fd9cf4b22a5 _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5)
                                                   #34 0x00007fd9cf4b99c0 _ZN12QApplication6notifyEP7QObjectP6QEvent (libQt5Widgets.so.5)
                                                   #35 0x00007fd9ceb35236 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5)
                                                   #36 0x00007fd9ceb3840b _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5)
                                                   #37 0x00007fd9ceb85a87 n/a (libQt5Core.so.5)
                                                   #38 0x00007fd9c727426d g_main_context_dispatch (libglib-2.0.so.0)
                                                   #39 0x00007fd9c7274638 n/a (libglib-2.0.so.0)
                                                   #40 0x00007fd9c72746d0 g_main_context_iteration (libglib-2.0.so.0)
                                                   #41 0x00007fd9ceb85813 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                                   #42 0x00007fd9ceb3417b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                                   #43 0x00007fd9ce99c046 _ZN7QThread4execEv (libQt5Core.so.5)
                                                   #44 0x00007fd9ce9a54bb n/a (libQt5Core.so.5)
                                                   #45 0x00007fd9c98d358e start_thread (libpthread.so.0)
                                                   #46 0x00007fd9c9802593 __clone (libc.so.6)

                                                   Stack trace of thread 28006:
                                                   #0  0x00007fd9c97f7371 __poll (libc.so.6)
                                                   #1  0x00007fd9c72745a6 n/a (libglib-2.0.so.0)
                                                   #2  0x00007fd9c72746d0 g_main_context_iteration (libglib-2.0.so.0)
                                                   #3  0x00007fd9c7274721 n/a (libglib-2.0.so.0)
                                                   #4  0x00007fd9c729d48a n/a (libglib-2.0.so.0)
                                                   #5  0x00007fd9c98d358e start_thread (libpthread.so.0)
                                                   #6  0x00007fd9c9802593 __clone (libc.so.6)

                                                   Stack trace of thread 28007:
                                                   #0  0x00007fd9c97f7371 __poll (libc.so.6)
                                                   #1  0x00007fd9c72745a6 n/a (libglib-2.0.so.0)
                                                   #2  0x00007fd9c72746d0 g_main_context_iteration (libglib-2.0.so.0)
                                                   #3  0x00007fd9b51ebc7d n/a (libdconfsettings.so)
                                                   #4  0x00007fd9c729d48a n/a (libglib-2.0.so.0)
                                                   #5  0x00007fd9c98d358e start_thread (libpthread.so.0)
                                                   #6  0x00007fd9c9802593 __clone (libc.so.6)

                                                   Stack trace of thread 27878:
                                                   #0  0x00007fd9c97f7371 __poll (libc.so.6)
                                                   #1  0x00007fd9c72745a6 n/a (libglib-2.0.so.0)
                                                   #2  0x00007fd9c72746d0 g_main_context_iteration (libglib-2.0.so.0)
                                                   #3  0x00007fd9ceb85813 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                                   #4  0x00007fd9b6c47f15 n/a (libQt5XcbQpa.so.5)
                                                   #5  0x00007fd9ceb3417b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                                   #6  0x00007fd9ceb3c246 _ZN16QCoreApplication4execEv (libQt5Core.so.5)
                                                   #7  0x00007fd9d0f36b79 _ZN6octave15gui_application7executeEv (liboctgui.so.4)
                                                   #8  0x0000000000402379 main (lt-octave-gui)
                                                   #9  0x00007fd9c9729413 __libc_start_main (libc.so.6)
                                                   #10 0x000000000040263e _start (lt-octave-gui)

                                                   Stack trace of thread 28005:
                                                   #0  0x00007fd9c97f7371 __poll (libc.so.6)
                                                   #1  0x00007fd9c6fe139f n/a (libxcb.so.1)
                                                   #2  0x00007fd9c6fe301a xcb_wait_for_event (libxcb.so.1)
                                                   #3  0x00007fd9b6bb4da9 n/a (libQt5XcbQpa.so.5)
                                                   #4  0x00007fd9ce9a54bb n/a (libQt5Core.so.5)
                                                   #5  0x00007fd9c98d358e start_thread (libpthread.so.0)
                                                   #6  0x00007fd9c9802593 __clone (libc.so.6)

                                                   Stack trace of thread 28013:
                                                   #0  0x00007fd9c973e30c __sigtimedwait (libc.so.6)
                                                   #1  0x00007fd9c98ddafc sigwait (libpthread.so.0)
                                                   #2  0x00007fd9ce2c35a2 signal_watcher (liboctave.so.6)
                                                   #3  0x00007fd9c98d358e start_thread (libpthread.so.0)
                                                   #4  0x00007fd9c9802593 __clone (libc.so.6)

                                                   Stack trace of thread 28010:
                                                   #0  0x00007fd9c97f7371 __poll (libc.so.6)
                                                   #1  0x00007fd9c72745a6 n/a (libglib-2.0.so.0)
                                                   #2  0x00007fd9c72746d0 g_main_context_iteration (libglib-2.0.so.0)
                                                   #3  0x00007fd9ceb85813 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
                                                   #4  0x00007fd9ceb3417b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
                                                   #5  0x00007fd9ce99c046 _ZN7QThread4execEv (libQt5Core.so.5)
                                                   #6  0x00007fd9b6aedf89 n/a (libQt5DBus.so.5)
                                                   #7  0x00007fd9ce9a54bb n/a (libQt5Core.so.5)
                                                   #8  0x00007fd9c98d358e start_thread (libpthread.so.0)
                                                   #9  0x00007fd9c9802593 __clone (libc.so.6)

                                                   Stack trace of thread 28009:
                                                   #0  0x00007fd9c97f7371 __poll (libc.so.6)
                                                   #1  0x00007fd9c72745a6 n/a (libglib-2.0.so.0)
                                                   #2  0x00007fd9c7274962 g_main_loop_run (libglib-2.0.so.0)
                                                   #3  0x00007fd9b55fd79a n/a (libgio-2.0.so.0)
                                                   #4  0x00007fd9c729d48a n/a (libglib-2.0.so.0)
                                                   #5  0x00007fd9c98d358e start_thread (libpthread.so.0)
                                                   #6  0x00007fd9c9802593 __clone (libc.so.6)



Dmitri A. Sergatskov <dasergatskov>
Mon 19 Nov 2018 05:55:12 PM UTC, comment #2: 

Message truncated.  Re-posting.

I don't get a segfault, but there is certainly something weird going on.  I have constructed the files and directory structure that you specified and attached it as a tar.gz file to this report so that others can experiment more quickly.

When I run start_crash the first time I get


>> start_crash
warning: load_path: folder1: No such file or directory
warning: called from
    somefunc at line 2 column 3
    start_crash at line 2 column 1
warning: load-path: update failed for '', removing from path
warning: called from
    somefunc at line 2 column 3
    start_crash at line 2 column 1


When I run it the second time I get


warning: load_path: folder1: No such file or directory
warning: load-path: update failed for '', removing from path
warning: load_path: folder1: No such file or directory
warning: load-path: update failed for '', removing from path
error: octave_base_value::user_code_value(): wrong type argument '<unknown type>'


The warnings about a non-existent path ("folder1" in this case) are annoying because they repeat every time one returns to the prompt.

Something that I think may be relevant is that 'folder1' is not an absolute name.  I believe addpath is supposed to insure that relative paths are changed to absolute ones before it updates the PATH variable.

I'm adding jwe to the CC list.

Rik <rik5>
Group administrator
Mon 19 Nov 2018 05:54:36 PM UTC, comment #1: 

I don't get a segfault, but there is certainly something weird going on.  I have constructed the files and directory structure that you specified and attached it as a tar.gz file to this report so that others can experiment more quickly.

When I run start_crash the first time I get





(file #45491)

Rik <rik5>
Group administrator
Sat 17 Nov 2018 11:15:57 PM UTC, original submission:  

While hunting for another bug, I figured out the following problem with hg-id 2eb71b83d3e2 to 91a791a00186 (latest by now)

The setup

$ find
.
./start_crash.m
./folder1
./folder1/somefunc.m


start_crash.m

addpath ('folder1');  % Bad name on load-path
somefunc ()



folder1/somefunc.m

function somefunc ()
  cd ('..')
end


In Octave:

octave:1> start_crash
warning: load_path: folder1: No such file or directory
warning: called from
    somefunc at line 2 column 3
    start_crash at line 2 column 1
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)


In Octave 4.4.1 I get the warning but no seg. fault.

Kai Torben Ohlhus <siko1056>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #45561:  bug55046_format_octave_idx_type.patch added by mmuetzel (2KiB - application/octet-stream)
file #45552:  warn.list added by rik5 (7KiB - application/octet-stream)
file #45515:  bug55046_OCTAVE_FORMAT_ATTRIBUTE.patch added by siko1056 (2KiB - text/x-patch - This patch does not work yet.)
file #45493:  bug55046.cset added by rik5 (971B - application/octet-stream)
file #45491:  bug55046.tar.gz added by rik5 (314B - application/gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by siko1056 (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 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-04 rik5 StatusWorks For Me Fixed
        Open/ClosedOpen Closed
    2018-12-04 siko1056 StatusReady For Test Works For Me
        Assigned tosiko1056 None
    2018-12-04 mmuetzel StatusFixed Ready For Test
        Open/ClosedClosed Open
    2018-11-30 mmuetzel Attached File- Added bug55046_format_octave_idx_type.patch, #45561
        Operating SystemGNU/Linux Any
    2018-11-29 rik5 Attached File- Added warn.list, #45552
    2018-11-29 siko1056 StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2018-11-23 siko1056 StatusIn Progress Need Info
    2018-11-23 siko1056 Attached File- Added bug55046_OCTAVE_FORMAT_ATTRIBUTE.patch, #45515
    2018-11-23 siko1056 Assigned toNone siko1056
    2018-11-21 rik5 Severity4 - Important 3 - Normal
        StatusPatch Submitted In Progress
        SummaryCrash with trivial script on dev Add static compile-time checking of printf functions using compiler attributes
    2018-11-19 rik5 Attached File- Added bug55046.cset, #45493
    2018-11-19 rik5 StatusConfirmed Patch Submitted
    2018-11-19 rik5 Attached File- Added bug55046.tar.gz, #45491
        StatusNone Confirmed
        Carbon-Copy- Added jwe

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code