I got a relatively serious problem with boost::random.
Background: I'm using TDM-GCC x64 on Windows 7 x64. Compiler options are -g -Wall -fexceptions
I build Boost using the same compiler enviroment, but that shouldn't matter when using random since it is header-only(?)
So now my problem:
I got this function:
#define PRNG_GENERATOR boost::mt19937
COORD function_g(int depth)
{
double _range;
_range = 1/(depth + 1.0f);
boost::uniform_real<double> range(-_range, _range);
boost::variate_generator<PRNG_GENERATOR&, boost::uniform_real<double> > v_png(*this->m_prng, range);
return v_png();
}
When I call this function my program crashes with an c0000026 Error in the ntdll.dll module.
The crash is always displayed by gdb on the first line of the ()-operator of the random number engine of boost (in this case it is in the file mersenne_twiseter.hpp at line 319 which is "if(i == n)" - not actually something I would expect to cause a crash).
And the even more strange thing is, that this crash just appeared - I didn't commited any code changes, just a (clean) recompile and every build after the first showing the crash just crashes....!?
I spend now about one hour searching the internet for this mysterious c0000026 error, but didn't found anything valueable....
Someone got a tip how to resolve this issue?
You haven't shown us how this->m_prng is initialized. Are you sure it points to a valid
object of type boost::mt19937? The rest of it looks OK, as far as I can tell.
Related
Recently, I've been observing an issue that happens after copying a binary file over another binary file without first deleting it on my M1. After some experimentation (after hitting this issue), I've come up with a reproducible method of hitting this issue on Apple's new hardware on the latest 11.3 release of Big Sur.
The issue happens when copying a differing binary over another binary after they have been run at least once. Not sure what is causing this issue, but it's very perplexing and could potentially lead to some security issues.
For example, this produces the error:
> ./binaryA
# output A
> ./binaryB
# output B
> cp binaryA binaryB
> ./binaryB
Killed: 9
Setup
In order to reproduce the above behavior, we can create two simple C files with the following contents:
// binaryA.c
#include<stdio.h>
int main() {
printf("Hello world!");
}
// binaryB.c
#include<stdio.h>
const char s[] = "Hello world 123!"; // to make sizes differ for clarity
int main() {
printf("%s", s);
}
Now, you can run the following commands and get the error described (the programs must be run before the issue can be reproduced, so running the programs below is necessary):
> gcc -o binaryA binaryA.c
> gcc -o binaryB binaryB.c
> ./binaryA
Hello world!
> ./binaryB
Hello world 123!
> cp binaryA binaryB
> ./binaryB
Killed: 9
As you can see, the binaryB binary no longer works. For all intents and purposes, the two binaries are equal but one runs and one doesn't. A diff of both binaries returns nothing.
I'm assuming this is some sort of signature issue? But it shouldn't be because both binaries are not signed anyways.
Does anyone have a theory behind this behavior or is it a bug? Also, if it is a bug, where would I even file this?
Whenever you update a signed file, you need to create a new file.
Specifically, the code signing information (code directory hash) is hung off the vnode within the kernel, and modifying the file behind that cache will cause problems. You need a new vnode, which means a new file, that is, a new inode. Documented in WWDC 2019 Session 703 All About Notarization - see slide 65.
This is because Big Sur on ARM M1 processor requires all code to be validly signed (if only ad hoc) or the operating system will not execute it, instead killing it on launch.
While Trev's answer is technically correct (best kind of correct?), the likely answer is also that this is a bug in cp - or at least an oversight in the interaction between cp and the security sandbox, which is causing a bad user experience (and bad UX == bug in my book, no matter the intention)
I'm going to take a wild guess (best kind of guess!) and posit that when this was first implemented, someone hooked into the inode deletion as a trigger for resetting the binary signature state. It is very possible that, at the time that they implemented this, cp actually removed/destructively replaced the vnode/inode as part of the copy, so everything worked great. Then, at some point, someone else went and optimized cp to no longer be a destructive inode operation - and this is how the best bugs come to be!
When using CLion I have found the output sometimes cuts off.
For example when running the code:
main.cpp
#include <stdio.h>
int main() {
int i;
for (i = 0; i < 1000; i++) {
printf("%d\n", i);
}
fflush(stdout); // Shouldn't be needed as each line ends with "\n"
return 0;
}
Expected Output
The expected output is obviously the numbers 0-999 on each on a new line
Actual Output
After executing the code multiple times within CLion, the output often changes:
Sometimes it executes perfectly and shows all the numbers 0-999
Sometimes it cuts off at different points (e.g. 0-840)
Sometimes it doesn't output anything
The return code is always 0!
Screenshot
Running the code in a terminal (i.e. not in CLion itself)
However, the code outputs the numbers 0-999 perfectly when compiling and running the code using the terminal.
I have spent so much time on this thinking it was a problem with my code and a memory issue until I finally realised that this was just an issue with CLion.
OS: Ubuntu 14.04 LTS
Version: 2016.1
Build: #CL-145.258
Update
A suitable workaround is to run the code in debug mode (thanks to #olaf).
The consensus is that this is an IDE issue. Therefore, I have reported the bug.
A suitable workaround is to execute the code in debug mode (no breakpoint required).
I will update this question, as soon as this bug is fixed.
Update 1
WARNING: You should not change information in registry unless you have been asked specifically by JetBrains. Registry is not in the main menu for a reason! Use the following solution at your own risk!!!
JetBrains have contacted me and provided a suitable solution:
Go to the Find Action Dialog box (CTRL+SHIFT+A)
Search for "Registry..."
Untick run.processes.with.pty
Should then work fine!
Update 2
The bug has been added here:
https://youtrack.jetbrains.com/issue/CPP-6254
Feel free to upvote it!
I am working on a code that is crashing. I realized that the compiled program crashes when it is deallocating the variables, but I don't know how to fix it.
When I run the code, a pop-up from Windows appears saying:
main.exe has stopped working.
Windows can check for a solution to the problem.
and the compiler shows the message Process returned -1073740940 (0xC0000374) execution time : 1.171 s
Bellow there is a sample of the code:
Subroutine PoissonCode()
Use Mesh
Implicit none
Real(8), Allocatable :: u(:,:),v(:,:),p(:,:)
Character(50) :: Nome
Allocate(u(0:Imax,0:jmax),v(0:Imax,0:jmax),p(0:Imax,0:jmax),fx(0:Imax,0:jmax),fy(0:Imax,0:jmax))
Allocate(xd(0:Imax),yd(0:Jmax))
........Code Here...............
Deallocate(u,v,p,fx,fy,xd,yd)
Deallocate(xd,yd)
End Subroutine PoissonCode
I put the complete code here for further investigation.
I also tried to run the code with different versions of GFortran in Windows 7 x64 and Windows XP x86 with no success.
Edit:
The correct end of the code is:
...
Deallocate(u,v,p,fx,fy)
Deallocate(xd,yd)
End Subroutine PoissonCode
Up date:
I tested the code with a different compiler (Intel Visual Fortran) and still no success.
D'uhhhh (to all of us)
Deallocate(u,v,p,fx,fy,xd,yd)
Deallocate(xd,yd)
In the second line your program (attempts to) deallocate variables already deallocated in the first line. I suppose that sometimes it pays to read code posted.
deallocate has optional arguments stat and errmsg which can be used to catch this sort of mistake and provide an alternative to the default behaviour which is for the program to crash.
I'm working on the Pintos toy operating system at university, but there's a strange bug when using GCC 4.6.2. When I push my system call arguments (just 3 pushl-s in inline assembly), some mysterious data also appears on the stack, and the arguments are in the wrong order. Setting -fno-omit-frame-pointer gets rid of the strange data, but the arguments are still in the wrong order. GCC 4.5 works fine. Any idea what specific option could fix this?
NOTE: the problem still occurs with -O0.
Without a code example and a listing of the result from your different compilations, it's difficult to help you. But here are three possible causes for your problems:
Make sure you understand how arguments are pushed to the stack. Arguments are pushed from the back. This makes it possible for printf(char *, ...) to examine the first item to find out how many more there are. If you want to call the function int foo(int a, int b, int c), you'll need to push c, then b and finally a.
Could the strange data on the stack be a return address or EFLAGS? I don't know Pintos and how system calls are made, but make sure that you understand the difference between CALL/RET and INT/IRET. INT pushes the flags onto the stack.
If your inline assembly has side effects, you might want to write volatile/__volatile__ in front of it. Otherwise GCC is allowed to move it when optimizing.
I need to see your code to better understand what's going on.
The culprit was -fomit-frame-pointer, which has been enabled by default since 4.6.2. -fno-omit-frame-pointer fixed the issue.
Did you clean the parameters on stack after the syscall? gcc may not be aware that you touch the stack and generate code depends on the stack pointer it expected.
-fno-omit-frame-pointer force gcc to use e/rbp for accessing locate data but it just hide the actual problem.
I'm used to using gdb quite effectively when I am dealing with ELF binaries which have been compiled using the -ggdb flag. However there are a few difficulties I am facing when I am facing normal non-stripped binaries.
I can set the breakpoint at main, but what if I needed to set the breakpoint at a fixed offset(say 10 lines) from the start of main?
Usually I get the address of a character array(say buf) as print &buf. However, in the current case I get a message saying that buf cannot be found in the current context.
How do I deal with the above mentioned issues? It would be great if you could provide some reading material too.
To get things like source line number and variable information, your code needs to be compiled with debug symbols (-ggdb or similar). Compiling without debug symbols but unstripped keeps in function and global variable names, but nothing else. Stripping the executable even removes some of those. So, in answer to your question, you can't do the things you want without compiling with -g.