Bad executable

Bad executable

[gmail Vladimir Koković]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]


I'm not sure if this is a GCC bug so I'm looking for help.

Namely, although everything is regular when it comes to .C programs, the 
result is defective executable.

The complete NetBeans project is attached.


gcc --version
gcc (GCC) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


inxi --machine --graphics --cpu --system --audio
System:    Host: vlada-kuci Kernel: 5.12.9-1-MANJARO x86_64 bits: 64 
Desktop: KDE Plasma 5.21.5 Distro: Manjaro Linux
Machine:   Type: Desktop Mobo: ASUSTeK model: M5A78L-M PLUS/USB3 v: Rev 
X.0x serial: 160882541101074 BIOS: American Megatrends
            v: 0404 date: 06/27/2016
CPU:       Info: 8-Core model: AMD FX-8300 bits: 64 type: MCP cache: L2: 
2 MiB
            Speed: 1401 MHz min/max: 1400/3300 MHz Core speeds (MHz): 1: 
1401 2: 1441 3: 1403 4: 1399 5: 1405 6: 1406 7: 1405
            8: 1385
Graphics:  Device-1: NVIDIA GK208B [GeForce GT 710] driver: nvidia v: 
465.31
            Display: x11 server: X.Org 1.20.11 driver: loaded: nvidia 
resolution: 1920x1080~60Hz
            OpenGL: renderer: NVIDIA GeForce GT 710/PCIe/SSE2 v: 4.6.0 
NVIDIA 465.31
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] SBx00 Azalia 
driver: snd_hda_intel
            Device-2: NVIDIA GK208 HDMI/DP Audio driver: snd_hda_intel
            Sound Server-1: ALSA v: k5.12.9-1-MANJARO running: yes
            Sound Server-2: PulseAudio v: 14.2 running: yes

Vladimir Koković, DP senior(70), Serbia, Belgrade, 24.June 2021


[-- Attachment #2: vk-trace.tar.gz --]
[-- Type: application/gzip, Size: 212947 bytes --]

Re: Bad executable

[Jonathan Wakely]

On Thu, 24 Jun 2021 at 07:34, gmail Vladimir Koković via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
>
> I'm not sure if this is a GCC bug so I'm looking for help.
>
> Namely, although everything is regular when it comes to .C programs, the
> result is defective executable.

Defective how? You haven't even told us what the error is.

As it says at https://gcc.gnu.org/bugs/

"Before reporting that GCC compiles your code incorrectly, compile it
with gcc -Wall -Wextra and see whether this shows anything wrong with
your code. Similarly, if compiling with -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations makes a difference, or if compiling
with -fsanitize=undefined produces any run-time errors, then your code
is probably not correct. "

Have you tried those options?

Re: Bad executable

[gmail Vladimir Koković]

The NetBeans project contains all the elements of the build as well as 
compiler options.

To be clearer, here is output from the build:

cd '/asoft-src/ispp-64/linux/vk-trace'
/usr/bin/make -f Makefile CONF=Debug clean
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= 
.clean-conf
make[1]: Entering directory '/asoft-src/ispp-64/linux/vk-trace'
rm -f -r build/Debug
make[1]: Leaving directory '/asoft-src/ispp-64/linux/vk-trace'
CLEAN SUCCESSFUL (total time: 104ms)
cd '/asoft-src/ispp-64/linux/vk-trace'
/usr/bin/make -f Makefile CONF=Debug
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= 
.build-conf
make[1]: Entering directory '/asoft-src/ispp-64/linux/vk-trace'
"/usr/bin/make"  -f nbproject/Makefile-Debug.mk 
dist/Debug/GNU-Linux/vk-trace
make[2]: Entering directory '/asoft-src/ispp-64/linux/vk-trace'
mkdir -p build/Debug/GNU-Linux/_ext/5fd253b2
rm -f "build/Debug/GNU-Linux/_ext/5fd253b2/main.o.d"
gcc -ggdb3 -Og -gdwarf-2 -finstrument-functions -fPIC -save-temps   -c 
-g -Werror -D_GNU_SOURCE -MMD -MP -MF 
"build/Debug/GNU-Linux/_ext/5fd253b2/main.o.d" -o 
build/Debug/GNU-Linux/_ext/5fd253b2/main.o 
/asoft-src/ispp-64/linux/vk-trace/main.c
mkdir -p build/Debug/GNU-Linux/_ext/5fd253b2
rm -f "build/Debug/GNU-Linux/_ext/5fd253b2/vk-trace-unix.o.d"
gcc -ggdb3 -Og -gdwarf-2 -finstrument-functions -fPIC -save-temps   -c 
-g -Werror -D_GNU_SOURCE -MMD -MP -MF 
"build/Debug/GNU-Linux/_ext/5fd253b2/vk-trace-unix.o.d" -o 
build/Debug/GNU-Linux/_ext/5fd253b2/vk-trace-unix.o 
/asoft-src/ispp-64/linux/vk-trace/vk-trace-unix.c
mkdir -p dist/Debug/GNU-Linux
gcc -ggdb3 -Og -gdwarf-2 -finstrument-functions -fPIC -save-temps    -o 
dist/Debug/GNU-Linux/vk-trace build/Debug/GNU-Linux/_ext/5fd253b2/main.o 
build/Debug/GNU-Linux/_ext/5fd253b2/vk-trace-unix.o -shared -ludis86 
-ldl -Wl,-Map,/tmp/vk-trace.map
make[2]: Leaving directory '/asoft-src/ispp-64/linux/vk-trace'
make[1]: Leaving directory '/asoft-src/ispp-64/linux/vk-trace'
BUILD SUCCESSFUL (total time: 553ms)


[root@vlada-kuci tmp 13:00:34]$ 
/asoft-src/ispp-64/linux/vk-trace/dist/Debug/GNU-Linux/vk-trace
Segmentation fault (core dumped)
[root@vlada-kuci tmp 13:00:38]$


[root@vlada-kuci tmp 13:00:38]$ coredumpctl debug
            PID: 1254125 (vk-trace)
            UID: 0 (root)
            GID: 0 (root)
         Signal: 11 (SEGV)
      Timestamp: Thu 2021-06-24 13:00:38 CEST (1min 14s ago)
   Command Line: 
/asoft-src/ispp-64/linux/vk-trace/dist/Debug/GNU-Linux/vk-trace
     Executable: 
/asoft-src/ispp-64/linux/vk-trace/dist/Debug/GNU-Linux/vk-trace
  Control Group: 
/user.slice/user-0.slice/user@0.service/app.slice/app-org.kde.konsole-76c21b455646434185ef1b6624a919b8.scope
           Unit: user@0.service
      User Unit: app-org.kde.konsole-76c21b455646434185ef1b6624a919b8.scope
          Slice: user-0.slice
      Owner UID: 0 (root)
        Boot ID: 3844df00b5fb41bca52f50121ca9d8cf
     Machine ID: 27bff91dbe26453e8890335069c7071a
       Hostname: vlada-kuci
        Storage: 
/var/lib/systemd/coredump/core.vk-trace.0.3844df00b5fb41bca52f50121ca9d8cf.1254125.1624532438000000.zst 
(present)
      Disk Size: 5.8K
        Message: Process 1254125 (vk-trace) of user 0 dumped core.

                 Stack trace of thread 1254125:
                 #0  0x0000000000000001 n/a (n/a + 0x0)

GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
vk qt5printers
vk wx5printers
vk libpython
sys.version_info(major=3, minor=9, micro=5, releaselevel='final', serial=0)
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) 
[answered N; input not from terminal]
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) 
[answered N; input not from terminal]
Reading symbols from 
/asoft-src/ispp-64/linux/vk-trace/dist/Debug/GNU-Linux/vk-trace...
[New LWP 1254125]
Core was generated by 
`/asoft-src/ispp-64/linux/vk-trace/dist/Debug/GNU-Linux/vk-trace'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000001 in ?? ()
(gdb)

On 24.6.21. 11:06, Jonathan Wakely wrote:
> On Thu, 24 Jun 2021 at 07:34, gmail Vladimir Koković via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
>>
>> I'm not sure if this is a GCC bug so I'm looking for help.
>>
>> Namely, although everything is regular when it comes to .C programs, the
>> result is defective executable.
> Defective how? You haven't even told us what the error is.
>
> As it says at https://gcc.gnu.org/bugs/
>
> "Before reporting that GCC compiles your code incorrectly, compile it
> with gcc -Wall -Wextra and see whether this shows anything wrong with
> your code. Similarly, if compiling with -fno-strict-aliasing -fwrapv
> -fno-aggressive-loop-optimizations makes a difference, or if compiling
> with -fsanitize=undefined produces any run-time errors, then your code
> is probably not correct. "
>
> Have you tried those options?

Re: Bad executable

[gmail Vladimir Koković]

More details about the NetBeans project:

Main folder

-----------

/asoft-src/ispp-64/linux/vk-trace:
total 48
drwxr-xr-x 6 root root 4096 јун 24 08:38 .
drwxr-xr-x 9 root root 4096 јун 24 08:30 ..
drwxr-xr-x 3 root root 4096 јун 24 06:14 build
drwxr-xr-x 2 root root 4096 јун 24 06:17 CVS
-rw-r--r-- 1 root root   11 јун 23 06:52 .cvsignore
-rw-r--r-- 1 root root  163 јун 24 06:14 .dep.inc
drwxr-xr-x 3 root root 4096 јун 23 06:55 dist
-rw-r--r-- 1 root root 1635 јун 24 05:56 main.c
-rw-r--r-- 1 root root 3482 јун 23 06:52 Makefile
-rw-r--r-- 1 root root 1588 јун 23 18:53 mira.c
drwxr-xr-x 4 root root 4096 јун 24 00:04 nbproject
-rw-r--r-- 1 root root  851 јун 23 06:55 vk-trace-unix.c


Build folder

------------

/asoft-src/ispp-64/linux/vk-trace/build/Debug/GNU-Linux/_ext/5fd253b2:
total 712
drwxr-xr-x 2 root root   4096 јун 24 06:14 .
drwxr-xr-x 3 root root   4096 јун 24 06:14 ..
-rw-r--r-- 1 root root 131032 јун 24 06:14 main.i
-rw-r--r-- 1 root root 101712 јун 24 06:14 main.o
-rw-r--r-- 1 root root     88 јун 24 06:14 main.o.d
-rw-r--r-- 1 root root 247515 јун 24 06:14 main.s
-rw-r--r-- 1 root root  70809 јун 24 06:14 vk-trace-unix.i
-rw-r--r-- 1 root root  46808 јун 24 06:14 vk-trace-unix.o
-rw-r--r-- 1 root root    106 јун 24 06:14 vk-trace-unix.o.d
-rw-r--r-- 1 root root 105004 јун 24 06:14 vk-trace-unix.s


Dist folder

-----------

/asoft-src/ispp-64/linux/vk-trace/dist/Debug/GNU-Linux:
total 96
drwxr-xr-x 2 root root  4096 јун 24 06:14 .
drwxr-xr-x 3 root root  4096 јун 23 06:55 ..
-rwxr-xr-x 1 root root 89472 јун 24 06:14 vk-trace

On 24.6.21. 11:06, Jonathan Wakely wrote:
> On Thu, 24 Jun 2021 at 07:34, gmail Vladimir Koković via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
>>
>> I'm not sure if this is a GCC bug so I'm looking for help.
>>
>> Namely, although everything is regular when it comes to .C programs, the
>> result is defective executable.
> Defective how? You haven't even told us what the error is.
>
> As it says at https://gcc.gnu.org/bugs/
>
> "Before reporting that GCC compiles your code incorrectly, compile it
> with gcc -Wall -Wextra and see whether this shows anything wrong with
> your code. Similarly, if compiling with -fno-strict-aliasing -fwrapv
> -fno-aggressive-loop-optimizations makes a difference, or if compiling
> with -fsanitize=undefined produces any run-time errors, then your code
> is probably not correct. "
>
> Have you tried those options?

Re: Bad executable

[Xi Ruoyao]

On Thu, 2021-06-24 at 13:05 +0200, gmail Vladimir Koković via Gcc-help
wrote:
> compiler options.

We won't build something relying on hardcoded path "/asoft-src/ispp-64"
on our system.  Creating "/asoft-src" needs root privilege and it's bad
to use root privilege for some unauthorized code from email.

But just by reading your code: vk-trace is created by "gcc -shared", and
you can't run it directly.
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University

Re: Bad executable

[gmail Vladimir Koković]

I've been in 40 years, just root user, and there's no other user for me !

As for starting "gcc -shared", I need executable that can be run, and 
for which the dlopen can be made.

At this point, only dlopen is working.

On 24.6.21. 14:08, Xi Ruoyao wrote:
> On Thu, 2021-06-24 at 13:05 +0200, gmail Vladimir Koković via Gcc-help
> wrote:
>> compiler options.
> We won't build something relying on hardcoded path "/asoft-src/ispp-64"
> on our system.  Creating "/asoft-src" needs root privilege and it's bad
> to use root privilege for some unauthorized code from email.
>
> But just by reading your code: vk-trace is created by "gcc -shared", and
> you can't run it directly.

Re: Bad executable

[Jonathan Wakely]

On Thu, 24 Jun 2021 at 13:29, gmail Vladimir Koković
<vladimir.kokovic@gmail.com> wrote:
>
> I've been in 40 years, just root user, and there's no other user for me !

But you're asking other people to build and run your code as root,
that's ridiculous. Please read what I already pointed you to, at
https://gcc.gnu.org/bugs

As it says there, we do not want an archive of your entire project. We
are not going to run and debug your code for you. Use the sanitizers
and other tools to help you debug your own code.

If you have a question, we can try to help. But "here is my code,
figure out what's wrong with it" is just rude. Hire a consultant if
you want somebody to do that for you.

Re: Bad executable

[David Brown]

On 24/06/2021 13:05, gmail Vladimir Koković via Gcc-help wrote:
> The NetBeans project contains all the elements of the build as well as
> compiler options.
> 
> To be clearer, here is output from the build:
> 

<snip>

No one is going to be able to replicate your entire PC, IDE, build
environment, etc.  This is not paid support - no one is going to spend
the huge effort required here.  You get the compiler for free, and /you/
are expected to do the work required to write and debug your code.
People on this list (and other sources) that offer help for free do so
to aid fellow developers, but they have very limited time and scope for
doing so.  You have to help others help you.  You don't go to a car
enthusiast forum, say "there's something wrong in my car", show them a
photo of it and a complete list of serial numbers of every part in the
vehicle.  That is what you are doing here, and it won't get you anywhere.

Alternatively, you have to pay someone to help - there are many sources
of paid gcc support available (from Red Hat / IBM, Code Sourcery /
Mentor Graphics, and others).


So you have to figure out the important information, and the code that
is causing problems.  If it really does seem to be a gcc bug (these do
exist, but they are far rarer than bugs in programmer's code) then the
compiler version is important.  Compiler options are important.  Your
IDE and your machine details are irrelevant.

You should first try your code with the options that Jonathan suggested.
 You don't appear to have any warning checks enabled at all - expect to
see many warning messages when you have -Wall -Wextra enabled.  There is
a good chance this will lead to you finding the bug in your code that is
causing you trouble.

If you are still having problems, the next step is to get a /minimal/
sample code that demonstrates the problem.  Typically that could be 10
to 30 lines of code, with the only headers included being standard
library headers (so you can have <stdint.h>, but not <stat.h> or any
OS-specific headers, and certainly no project-specific headers).  During
this process, there is again a very good chance that you will spot the
problem yourself.

At this stage, you have code that other people can look at, and it makes
sense to show it to others (such as on this list) with a description of
what you think should happen, and what goes wrong.  Then people can help
and perhaps guess where the problem lies - or say if they think it is a
compiler bug.

A very useful tool here is the <https://godbolt.org> website, which has
an online compiler.  Put your code there, and you can test it with
different compilers and different options.  This is a huge help when
checking the results with different compiler versions.  And if your code
is too big for the web page to be practical, or you can't get it to
compile, then you have not yet got your minimal sample.


Hopefully this will help you find your problem yourself, or to present
it in a way that others will be able to help you.

David




> On 24.6.21. 11:06, Jonathan Wakely wrote:
>> On Thu, 24 Jun 2021 at 07:34, gmail Vladimir Koković via Gcc-help
>> <gcc-help@gcc.gnu.org> wrote:
>>>
>>> I'm not sure if this is a GCC bug so I'm looking for help.
>>>
>>> Namely, although everything is regular when it comes to .C programs, the
>>> result is defective executable.
>> Defective how? You haven't even told us what the error is.
>>
>> As it says at https://gcc.gnu.org/bugs/
>>
>> "Before reporting that GCC compiles your code incorrectly, compile it
>> with gcc -Wall -Wextra and see whether this shows anything wrong with
>> your code. Similarly, if compiling with -fno-strict-aliasing -fwrapv
>> -fno-aggressive-loop-optimizations makes a difference, or if compiling
>> with -fsanitize=undefined produces any run-time errors, then your code
>> is probably not correct. "
>>
>> Have you tried those options?
>