Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Mark Galeck]

I see, thank you Paul this is very helpful.  I know unfortunately this is going 
to happen to some of my users, and I don't want them to blame me :)  All these 
comments I will be able to give them some idea what the problem was.  



  From: Paul Smith 
 To: Mark Galeck ; Andreas Schwab ; 
"bo...@kolpackov.net" ; "bug-make@gnu.org" 
 
 Sent: Tuesday, August 21, 2018 5:34 AM
 Subject: Re: [bug #54529] [Makefile:5: foobar] Segmentation fault
   
On Tue, 2018-08-21 at 06:32 +, Mark Galeck wrote:
> Then why does the error say "make: ***" ?  Shouldn't Make be more
> robust and assertive in such a case, if a child crashes, to inform
> the user that it is not Make code?

That's the format that make uses when it shows that the recipe of a
target failed, regardless of how it failed.

If the command exited with an error code (rather than dumped core), it
would be:

  $ cat Makefile
  sometarget: ; exit 22

  $ make
  exit 22
  make: *** [Makefile:1: sometarget] Error 22

If the command exits with a signal, it will say that instead of "Error
22".  If the command exits with a core dump, then it says that.

In general make doesn't know what actual command was running.  Usually
make invokes the shell and passes a string to that shell and the shell
runs it, and make doesn't know what actual commands that string is
running when it exits.  So make prints the target name, not the
command.  In the case of a program exiting with a core dump of course
make knows which command dumped core (it's whatever program make
invoked) but still make keeps the same syntax and behavior to be
consistent.

> Does the error message as it is, is it not _exactly_ the same as if
> Make itself crashed?  If so, then how is the user to know, whether
> this is a bug or not?

If make dumps core then it's up to the command that INVOKED make to
tell you about it.  Make cannot tell you about it... it dumped core!

It's up to the invoking program as to how it displays information that
its child dumped core.  If you invoke the command from the shell, for
example, then you get something like:

  $ ./badprogram
  core dumped

> I can't tell my users "hey, if this happens, read Make source to find
> out if it is really Make bug".

If you get a core dump and you don't know which program failed then the
best thing to do is to use file(1) on the core file to see which
program dumped core:

  $ file core.12343 
  core.12343: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, 
from 'badprogram'

But in general, if you see an error message in the format of standard
make errors ("make: ***") then you know it was not that make program
itself that failed, but rather the program that make invoked.


   ___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Paul Smith]

On Tue, 2018-08-21 at 06:32 +, Mark Galeck wrote:
> Then why does the error say "make: ***" ?  Shouldn't Make be more
> robust and assertive in such a case, if a child crashes, to inform
> the user that it is not Make code?

That's the format that make uses when it shows that the recipe of a
target failed, regardless of how it failed.

If the command exited with an error code (rather than dumped core), it
would be:

  $ cat Makefile
  sometarget: ; exit 22

  $ make
  exit 22
  make: *** [Makefile:1: sometarget] Error 22

If the command exits with a signal, it will say that instead of "Error
22".  If the command exits with a core dump, then it says that.

In general make doesn't know what actual command was running.  Usually
make invokes the shell and passes a string to that shell and the shell
runs it, and make doesn't know what actual commands that string is
running when it exits.  So make prints the target name, not the
command.  In the case of a program exiting with a core dump of course
make knows which command dumped core (it's whatever program make
invoked) but still make keeps the same syntax and behavior to be
consistent.

> Does the error message as it is, is it not _exactly_ the same as if
> Make itself crashed?  If so, then how is the user to know, whether
> this is a bug or not?

If make dumps core then it's up to the command that INVOKED make to
tell you about it.  Make cannot tell you about it... it dumped core!

It's up to the invoking program as to how it displays information that
its child dumped core.  If you invoke the command from the shell, for
example, then you get something like:

  $ ./badprogram
  core dumped

> I can't tell my users "hey, if this happens, read Make source to find
> out if it is really Make bug".

If you get a core dump and you don't know which program failed then the
best thing to do is to use file(1) on the core file to see which
program dumped core:

  $ file core.12343 
  core.12343: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, 
from 'badprogram'

But in general, if you see an error message in the format of standard
make errors ("make: ***") then you know it was not that make program
itself that failed, but rather the program that make invoked.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Edward Welbourne]

On Aug 21 2018, Mark Galeck  wrote:
>> Then why does the error say "make: ***" ?

Andreas Schwab (21 August 2018 09:42) replied:
> Because it's the messenger.

Indeed.  It remains that the message is apt to confuse a user.  If the
message included (at least the name of) the command that failed,

  make: 'touch' failed: *** Segmentation fault

it would be less confusing,

Eddy.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Andreas Schwab]

On Aug 21 2018, Mark Galeck  wrote:

> Then why does the error say "make: ***" ?

Because it's the messenger.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Mark Galeck]

No problem, thank you for explaining.  I still think that Make if it invokes a 
program directly, and the program crashes, Make should say something that will 
help the user understand it is not Make bug.  There has to be a way to print a 
more informative error message. 
Does the error message as it is, is it not _exactly_ the same as if Make itself 
crashed?  If so, then how is the user to know, whether this is a bug or not?  
By studying Make source? - this is a non-starter.  I can't tell my users "hey, 
if this happens, read Make source to find out if it is really Make bug".  

  From: Paul D. Smith 
 To: Henrik Carlqvist ; Mark Galeck 
; Paul D. Smith ; Martin Dorey 
; bo...@kolpackov.net; bug-make@gnu.org 
 Sent: Monday, August 20, 2018 11:33 AM
 Subject: [bug #54529] [Makefile:5: foobar] Segmentation fault
   
Update of bug #54529 (project make):

                  Status:                    None => Not A Bug              
            Open/Closed:                    Open => Closed                

    ___

Follow-up Comment #4:

This message:


$ make-4.2.1/make
touch foobar
make: *** [Makefile:5: foobar] Segmentation fault (core dumped) 


doesn't mean that make dumped core.  If it had you'd not see the prefix
containing the make target name, etc.

This means that the program make invoked dumped core.  Make is printing out
the results of invoking the program (specifically, the results of the
waitpid() call waiting for the child to complete).  In this case, since this
is a simple command so make can invoke it directly without using the shell, it
means that the "touch" program dumped core.

I suspect that your attempt to modify the LD_LIBRARY_PATH has caused an
incompatible version of the C runtime library (libc) or similar to be loaded
when the "touch" program is running.

I can't explain your "delete any elements and it doesn't happen" result,
except of course that if you modify the pathname you are using with "echo",
then the value of the ROOT make variable will change and the LD_LIBRARY_PATH
value will be different and thus it may not find the wrong library.

I can't see any way this can be related to make so I'm closing this as "not a
bug" but if you have more information feel free to add it as a comment and I
can re-open.

    ___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54529>

___
  Message sent via Savannah
  https://savannah.gnu.org/



   ___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #54529] [Makefile:5: foobar] Segmentation fault

[Paul D. Smith]

Update of bug #54529 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

This message:


$ make-4.2.1/make
touch foobar
make: *** [Makefile:5: foobar] Segmentation fault (core dumped) 


doesn't mean that make dumped core.  If it had you'd not see the prefix
containing the make target name, etc.

This means that the program make invoked dumped core.  Make is printing out
the results of invoking the program (specifically, the results of the
waitpid() call waiting for the child to complete).  In this case, since this
is a simple command so make can invoke it directly without using the shell, it
means that the "touch" program dumped core.

I suspect that your attempt to modify the LD_LIBRARY_PATH has caused an
incompatible version of the C runtime library (libc) or similar to be loaded
when the "touch" program is running.

I can't explain your "delete any elements and it doesn't happen" result,
except of course that if you modify the pathname you are using with "echo",
then the value of the ROOT make variable will change and the LD_LIBRARY_PATH
value will be different and thus it may not find the wrong library.

I can't see any way this can be related to make so I'm closing this as "not a
bug" but if you have more information feel free to add it as a comment and I
can re-open.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Andreas Schwab]

On Aug 17 2018, Mark Galeck  wrote:

> For this Makefile:
>
> ROOT := ${shell echo
> /home/mgaleck/ws/mgaleck_build/mgaleck_build_refactor2/target | sed s/t/t/}
> export LD_LIBRARY_PATH := ${ROOT}/usr/lib64:${LD_LIBRARY_PATH}
>
> foobar:
> touch $@
>
>
> and file foobar missing, then on some Linux distributions, I get this:
>
> $ make-4.2.1/make
> touch foobar
> make: *** [Makefile:5: foobar] Segmentation fault (core dumped)

Which means that the executed command has crashed, probably because of
some incompatible libraries in the LD_LIBRARY_PATH as set above.
Nothing to do with make.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Mark Galeck]

Brian,
the only thing that got "lost" was the tab before the recipe.  Everything else 
is as intended, I checked that.  
Yes it is the nature of an SSCCE that it "does not make sense", that is 
intentional, because the example is pared down to the smallest possible that 
reproduces the problem.  
Yes that means if I remove some characters from the path, even one character, 
the problem does not happen.  

This discussion is not about whether the code is good style or poor style.  It 
is not my code anyway and I don't have marching orders to change it.  

This discussion is about the message from GNU Make that says "segmentation 
fault", which I take it means, for sure, GNU Make has a bug - regardless of how 
ugly the makefile code may be, or even erroneous.  Please correct me if I am 
wrong on this one.  
I already found a "workaround" in my case, that is not the point.  The point is 
that there is a bug that IMHO should be fixed.  I tried to zero in on it myself 
but as I showed from the error messages, I have not gotten anywhere and to 
investigate further I would have to study some things that I don't know, and it 
would take me time that I don't have.  So I am hoping there is someone here 
that has more knowledge than me, and does not have to study and from the error 
messages can get a pretty good idea exactly what is happening, right away.  
Since it looks like I am in possession of the only system on which this does 
crash, I am willing to edit the makefile any way you like and execute any 
commands you want, so you can zero in on the bug.  
But myself I reached the end of the time that I can devote to my own research 
on this, given the knowledge I possess.  
Mark

  From: Brian Vandenberg 
 To: 
Cc: Henrik Carlqvist ; Mark Galeck ; 
Martin Dorey ; Paul D. Smith ; Boris 
Kolpackov ; bug-make 
 Sent: Saturday, August 18, 2018 2:05 PM
 Subject: Re: [bug #54529] [Makefile:5: foobar] Segmentation fault
   
I forgot to finish before hitting send.

I'm unable to reproduce this in RHEL6 with make 4.1 or Solaris 10 with
make 4.2.1.

Generally it's considered a bad idea / poor form to use
LD_LIBRARY_PATH.  This could easily explain why we cannot reproduce
it.  If you have something in that path that somehow causes this
problem, you're also the only one that could diagnose it.

Once you resolve this (or prove that using LD_LIBRARY_PATH is somehow
causing it), it would probably be worthwhile to find out why you find
yourself in need of LD_LIBRARY_PATH then find a better way to solve
that problem.

-brian

On Sat, Aug 18, 2018 at 2:52 PM, Brian Vandenberg
 wrote:
>> OK, the only system for which this bugs actually shows up, is work build
>> server, and unfortunately, the IT guy does not know where the cores are, and
>> gdb is not working.  Let me talk to him about fixing gdb and I will get back
>> to you what I find from it.
>
> This may depend on the distribution, but:
>
> cat /proc/sys/kernel/core_pattern
>
> The default tends contain the single word "core" with no extra frills
> (though if I'm wrong look in "man -s5 core" for info on deciphering
> the pattern it contains).  Assuming it just says "core" then it should
> dump to whatever the current working directory is for the process
> that's dying.
>
> Additionally, the default is usually to have coredumps disabled.  You
> can enable it in bash with:
>
> ulimit -c unlimited
>
>> The above Makefile is SSCCE for me - if I delete any elements from the above,
>> even just one letter from the echo string, does not happen.
>
> ... to include spaces, tabs and newlines?  What about changing the
> path that was being printed inside $(shell)?
>
> You may want to see if you can come up with a variant on this crash
> that doesn't involve characters that may change in an email.  For
> example, this looks strange:
>
> (...) | sed s/t/t}
>
> ... and makes me suspect something was lost in transliteration.
>
> -brian


   ___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Brian Vandenberg]

I forgot to finish before hitting send.

I'm unable to reproduce this in RHEL6 with make 4.1 or Solaris 10 with
make 4.2.1.

Generally it's considered a bad idea / poor form to use
LD_LIBRARY_PATH.  This could easily explain why we cannot reproduce
it.  If you have something in that path that somehow causes this
problem, you're also the only one that could diagnose it.

Once you resolve this (or prove that using LD_LIBRARY_PATH is somehow
causing it), it would probably be worthwhile to find out why you find
yourself in need of LD_LIBRARY_PATH then find a better way to solve
that problem.

-brian

On Sat, Aug 18, 2018 at 2:52 PM, Brian Vandenberg
 wrote:
>> OK, the only system for which this bugs actually shows up, is work build
>> server, and unfortunately, the IT guy does not know where the cores are, and
>> gdb is not working.  Let me talk to him about fixing gdb and I will get back
>> to you what I find from it.
>
> This may depend on the distribution, but:
>
> cat /proc/sys/kernel/core_pattern
>
> The default tends contain the single word "core" with no extra frills
> (though if I'm wrong look in "man -s5 core" for info on deciphering
> the pattern it contains).  Assuming it just says "core" then it should
> dump to whatever the current working directory is for the process
> that's dying.
>
> Additionally, the default is usually to have coredumps disabled.  You
> can enable it in bash with:
>
> ulimit -c unlimited
>
>> The above Makefile is SSCCE for me - if I delete any elements from the above,
>> even just one letter from the echo string, does not happen.
>
> ... to include spaces, tabs and newlines?  What about changing the
> path that was being printed inside $(shell)?
>
> You may want to see if you can come up with a variant on this crash
> that doesn't involve characters that may change in an email.  For
> example, this looks strange:
>
> (...) | sed s/t/t}
>
> ... and makes me suspect something was lost in transliteration.
>
> -brian

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #54529] [Makefile:5: foobar] Segmentation fault

[Brian Vandenberg]

> OK, the only system for which this bugs actually shows up, is work build
> server, and unfortunately, the IT guy does not know where the cores are, and
> gdb is not working.  Let me talk to him about fixing gdb and I will get back
> to you what I find from it.

This may depend on the distribution, but:

cat /proc/sys/kernel/core_pattern

The default tends contain the single word "core" with no extra frills
(though if I'm wrong look in "man -s5 core" for info on deciphering
the pattern it contains).  Assuming it just says "core" then it should
dump to whatever the current working directory is for the process
that's dying.

Additionally, the default is usually to have coredumps disabled.  You
can enable it in bash with:

ulimit -c unlimited

> The above Makefile is SSCCE for me - if I delete any elements from the above,
> even just one letter from the echo string, does not happen.

... to include spaces, tabs and newlines?  What about changing the
path that was being printed inside $(shell)?

You may want to see if you can come up with a variant on this crash
that doesn't involve characters that may change in an email.  For
example, this looks strange:

(...) | sed s/t/t}

... and makes me suspect something was lost in transliteration.

-brian

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #54529] [Makefile:5: foobar] Segmentation fault

[Mark Galeck]

Follow-up Comment #3, bug #54529 (project make):

OK, the only system for which this bugs actually shows up, is work build
server, and unfortunately, the IT guy does not know where the cores are, and
gdb is not working.  Let me talk to him about fixing gdb and I will get back
to you what I find from it.  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #54529] [Makefile:5: foobar] Segmentation fault

[Henrik Carlqvist]

Follow-up Comment #2, bug #54529 (project make):

"Segmentation fault (core dumped)" means that you got a core file to analyze.
A first simple step might be to see what generated that core file, it could be
done with something like "file core". Next you might want to open the core
file in a debugger to see a stack trace.

regards Henrik

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #54529] [Makefile:5: foobar] Segmentation fault

[Martin Dorey]

Follow-up Comment #1, bug #54529 (project make):

Easily put back but I think the bug reporting thing has eaten a tab.  Using a
semicolon rather than newline and tab would avoid that.  I can't reproduce the
crash.  I'm using the latest from git.  If I were you, I'd run it under
valgrind, then you'd probably get a stack trace, although perhaps it would
heisenbug away.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #54529] [Makefile:5: foobar] Segmentation fault

[Mark Galeck]

URL:
  

 Summary: [Makefile:5: foobar] Segmentation fault
 Project: make
Submitted by: mark_galeck0
Submitted on: Fri 17 Aug 2018 02:46:42 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2.1
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

For this Makefile:

ROOT := ${shell echo
/home/mgaleck/ws/mgaleck_build/mgaleck_build_refactor2/target | sed s/t/t/}
export LD_LIBRARY_PATH := ${ROOT}/usr/lib64:${LD_LIBRARY_PATH}

foobar:
touch $@


and file foobar missing, then on some Linux distributions, I get this:

$ make-4.2.1/make
touch foobar
make: *** [Makefile:5: foobar] Segmentation fault (core dumped)


The above Makefile is SSCCE for me - if I delete any elements from the above,
even just one letter from the echo string, does not happen.  

This happens on CentOS 7.3, but on latest Ubuntu, does not happen.  I am
hoping that this is merely a matter of different timing and the bug is really
present on all OS and a person sufficiently familiar with the code can see it
from the above description.  

Mark  




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make