I am running systemtap 4.7 on Centos 8 with a 4.18 kernel and using GCC 8.5.0
When I have systemtap produce a user-code backtrace, it never manages to find the filenames and line numbers for my source functions, despite there being a full .debuginfo installed, as well as a .debugsource. GDB finds this information without difficulty. I am using a -d option to point to my library.
There was a similar question asked here: systemtap probing by line number "analysis failed" but its only suggestion is that one doesn't have full debuginfo. I do. So, what else might be wrong?
Related
I recently downloaded the source for HDF5 (hdf5-1.12.1) and am building it on Ubuntu 20.04. The number of compiler warnings is remarkable ---the messages reference -Wnull-dereference, -stringop-truncation, -Wcast-qual, -Wstrict-overflow ....
It's possible my system is configured by default to have more warnings than usual, but even so, I wouldn't expect something with this wide a distribution to fail so many warning checks. Any thoughts, beyond "don't run with strict checking"? If anyone is on the source side of HDF5, is this something you are aware of?
I've been using GSView 5.0 and GhostScript 9.52 to do postscript printing on vellums. However, today GSView started throwing error codes on every .ps file I've attempted to print. I'm using Windows 10 Pro and the printer is an Epson Artisan 1430.
The error is as follows:
GPL Ghostscript 9.52: **** Could not open file 00000e60.
Unrecoverable error: invalidfileaccess in showpage
Operand stack:
--nostringval-- 1 true
gsapi_execute_cont returns -9
gsapi_exit returns 0
I've tried changing permissions for the files and different printer drivers to no avail. I'm sorry I can't be more descriptive on this issue as it's hard to articulate.
OK... You must have recently updated to a new version of Ghostscript. I can reproduce your problem, and it comes down to a recent (documented) change in behaviour for Ghostscript.
Due to the well-documented public disclosure of security exploits using Ghostscript a couple of years ago, the current version (and any version since 9.50) now defaults to running in SAFER mode.
When running in SAFER, Ghostscript prevents access by the PostScript interpreter to the file system. For those unaware of the problem; PostScript is a full-blown programming language and, by design, permits programs to access the underlying file system. SAFER mode prevents this so that malicious PostScript programs cannot, for example, run arbitrary code on your computer.
It seems that GSView is using Ghostscript in a way which requires it to read the PostScript program to be printed using the PostScript interpreter, instead of the more normal practice of specifying the input file as one of the arguments. For simplicity the input file is granted read availability by the Ghostscript executable. I suspect that GSview is using the DLL directly and not adding that extra information.
Now there are ways to permit access to specific files or folders, so that existing PostScript programs can continue to work, but obviously this requires some changes in the calling application. GSview has not changed in, literally, years so obviously it does not take any such action.
You can, however, get GSview to work as before. Under Options select Advanced Configure. In the resulting dialog look for the 'Ghostscript options' text box. In there add -dNOSAFER, that should get it to work again, though you may have to reboot the computer if the OS print subsystem has stalled.
Yes, this does open you up to the sorts of exploits I alluded to above, you should only do this with PostScript programs that you trust.
I'm trying to build Premake5 on FreeBSD 10.1 from the sources. I eventually got it to compile by removing the "-dl" option and using gmake explicitly for the build. It built, but I can't get it to do anything but spit out the following error message. Doesn't matter how I invoke it. It crashes even on 'premake5 --help'.
Here's the message:
PANIC: unprotected error in call to Lua API (attempt to call a string value)
The code is buggy as all get-out. It starts by assuming linux is posix which is clearly not the case. They use linuxism all over the place so converting to posix is going to be quite a task, and until that is done it will never work satisfactorily on non-linux posix based systems.
The -ldl was obviously the first stumbling block. The next is in the function premake_locate_executable in premake.c. In this they are using the /proc filesystem which is a linuxism and since this fails on BSD they are falling back to some lua methods but they seem to be assuming that lua_tostring pops the corresponding value which it doesn't. Since their stack isn't balanced in this function the following lua_call is trying to call the garbage they've left on the stack rather than the function they intended.
Even after I fixed this issue they use getconf _NPROCESSORS_ONLN to get the number of cores to multi-job the make build but they don't actually check that this call succeeds (which it doesn't outside of Linux and MacOSX).
After fixing this issue I then ran into the problem that their makefiles aren't regular make, but GNU-make, so I had to change to using gmake to try and build.
From that point it just came unravelled because none of the premake files in the contrib directory are configured for BSD despite it being one of the legal configuration targets (i.e. it doesn't default to linux) and so there is no configuration for those components.
TLDR: BSD is not a supported platform
I'm interested in playing around with the MaxSAT/MaxSMT c example (specifically, maxsat.c) provided on the z3 (Microsoft Research) website. Using Visual Studio 2010, I eventually got the example to compile (using a fresh install of z3 4.0). However, I can't get any of my (SMT 2.0) models to run using them. Further, I cannot get the example posted in this question to work either.
In the first case, my compiled program crashes when it tries to call Z3_get_smtlib_num_formulas in get_hard_constraints of the file. I don't know why, instead, I get the standard windows 7 "this program has stopped working" popup.
In the second case, it reports unsupported ;benchmark.
In order to help me to get this work, I was wondering if
(a) Has anyone had similar issues when compiling this code, and if so, how did you resolve them?
or
(b) How can I debug either compilation of the file (assuming it is correct)? Namely, can someone enumerate the correct libraries (and library versions - e.g., z3 4.0?) to include in the compiler options to get this example working?
In either case, information on the error reported in the second case would also be appreciated: what does it mean exactly? The keyword was not valid? That the SMT input is the wrong version? Or something else?
Thanks.
The MaxSAT example has not been updated to SMTLIB 2.0 yet. It uses the function Z3_parse_smtlib_file to parse the input, which means that it supports only SMTLIB 1.0 at the moment.
This example is distributed alongside Z3, i.e., you should have received a copy in Z3-4.0/examples/maxsat/, which also contains compilation and execution scripts.
Compilation should be straight-forward by running build.cmd in a Visual Studio Command Prompt, or build.sh on Linux.
I'm producing builds using MSBuild, and build configurations set up in the dproj on the command line. It's slightly disconcerting that the size of the executables thus produced are different (not by much, but still!) to what an IDE build produces. Any ideas why? I would have thought the same compiler is used?
The main power of building from the Delphi command-line compiler is standardization - you explicitly identify the options (on the command line, in the .cfg files, etc), and the compiler follows the options provided exclusively. In contrast, the IDE has many other behaviors that are not clear and explicit - for example, it may search library paths not specified in the Project Options. My guess is that something's happening in the IDE build of which you're not entirely aware - and this is why standardized builds are done from the command line.
To see what IDE is doind, check
Tools | Options | Environment Options | Compiling and Running | Show Command Line
And you can check the compiler messages.
The first answer on using the command line for build consistency is right on and it is probably something you needn't worry about if you are relying on a build system where production files are always sourced from the console builds.
On the other hand, if you really do want to figure out what is going on you should turn on map files (at the full detail level) and compare/diff them. If there are differences between the two they will show up there. Any other differences that may exist are likely a result of a commmand line option being different (such as a conditional flag that may be set in the IDE settings).
This behavior has existed in every version of Delphi I've used. (5 - 2006). I wouldn't worry to much about it. When I first discovered it I spent a lot of time trying to resolve the difference. Did I miss a compiler flag? Is there a discrepancy between the IDE and the command line compiler's supported options?
In the end I decided it wasn't that big of an issue. Both consistently produced functionally equivalent executables.
If you supply exactly the same params to the command line compiler the produced executables will virtually be identical.
In fact the IDE just calls the commandline compiler. Compile your project in the IDE and look at the messages window. you will see the full dcc32.exe call ...