I am getting a storage fault when my code destructs a regex and I am mystified as to the reason. I suspect I am missing something stupid about regex.
A little background: I am a reasonably experienced C++ developer but this is my first adventure with the regex class. My environment is a little unusual: I edit and alpha test in MS Visual C++ and then take the code to another environment. The other environment is fully Posix-compliant and just happens to be an IBM mainframe. The code works fine on Windows but fails every time on the mainframe. The problem is not something fundamental to my mixed environment: I have been working in this pair of environments in this way for years with complete C++ success.
I define the regex in the class declaration:
#include <regex>
...
class FilterEvalEGNX : public FilterEval
{
...
std::tr1::basic_regex<char> regexObject;
// I also tried plain regex with no difference
Subsequently in the class implementation I assign a pattern to the regex. The code should be more complex than this but I simplified it down to assigning a static string to eliminate any possible side effects from the way the string would be handled in real life.
std::tr1::regex::flag_type flags = std::tr1::regex::extended;
// I have also tried ECMA and it made no difference
try
{
static const char pat[] = "(ISPPROF|SPFTEMP)";
regexObject.assign(pat, flags);
}
catch (std::tr1::regex_error &e)
{
// handle regex error
}
That works without error. Of course, there is subsequent pattern matching code but it is not part of the problem: if I destruct the class immediately after the above code I get the storage fault.
I don't do anything to the regex in my class destructor. The rest of the class has been working for years; I am adding the regex now. I think some "external" overlay of the regex is unlikely.
Here is the traceback of the calls leading up to the fault:
std::tr1::_EBCDIC::_Destroy(std::tr1::_EBCDIC::_Node_base*)
+00000066 40 CRTE128N Exception
std::tr1::_EBCDIC::basic_regex<char,std::tr1::_EBCDIC::regex
+000000C8 2022 FilterEvalEGNX.C Call
std::tr1::_EBCDIC::basic_regex<char,std::tr1::_EBCDIC::regex
+0000007C 1913 FilterEvalEGNX.C Call
FilterEvalEGNX::~FilterEvalEGNX()
The code in the vicinity of line 1913 of regex is
~basic_regex()
{ // destroy the object
_Tidy();
}
The code in the vicinity of line 2022 of regex is
void _Tidy()
{ // free all storage
if (_Rep && --_Rep->_Refs == 0)
_Destroy(_Rep);
_Rep = 0;
}
_Destroy() appears to be implemented in the run-time and I do not think I have the source.
Any ideas? Thanks,
Believe it or not, it appears to be a bug in the C++ runtime. I tweaked my simple example and now I can duplicate the problem in a 15-line main(). I am going to run this by some peers and then report it to IBM. They actually fix this stuff! They don't just respond with "yes, you have found an issue."
Related
This is my first question ever posted, so please let me know if there is anything that needs changes in my post :)
I am currently working on a dialog that is supposed to let the user change the background-color for some signal plotting. The "wxColourPickerCtrl" seems to do exactly what I need. Since there are multiple plots/pictures to be manipulated, the ColourPickerCtrls are initialized in a loop with the chosen background color as the default value:
for (const auto& [signalName, signalProperties] : properties)
{
wxColourPickerCtrl* selectBackgroundColor = new wxColourPickerCtrl(this, signalProperties.first, signalProperties.second.backgroundColor, wxDefaultPosition, wxDefaultSize);
}
"this" is an object of type SignalPropertiesDialog, which is directly inherited from wxDialog.
I have left out all the necessary sizer stuff, since it's not relevant for the problem (at least imo). "properties" is structured as follows:
std::map<std::string, std::pair<int, GraphPicture::Properties>> signalProperties_;
where GraphPicture::Properties contains the properties I want to manipulate:
struct Properties
{
wxColour backgroundColor{ *wxWHITE };
wxColour lineColor{ *wxBLACK };
int linewidth_px{ 1 };
bool isShown{ true };
};
The application successfully builds but immediately crashes on startup while generating those color picker objects.
wxIshiko has uploaded multiple tutorials and code snippets as examples for various wxWidgets controls, including the wxColourPickerCtrl. So I downloaded the sample code and tried to run it. Surprisingly, it worked.
While running through the code step by step I noticed the following difference:
The wxColourPickerCtrl is based on wxPickerBase. The wxPickerBase is created by calling the constructor of wxColourPickerCtrl (what I am actually doing in my code). During the construction of the wxPickerBase, the desired color is called by the name wxColourDataBase::FindName(const wxColour& color) const where the wxColourBase itself is instantiated. This is where the difference is:
When running the code snippet by wxIshiko, wxColourDataBase is instantiated correctly including the member m_map of type wxStringToColourHashMap* which is set to be NULL.
When running the code written by myself, wxColourDataBase is not correctly instantiated, and thus the member m_map is not set to be NULL, which leads to to the crash.
I have the feeling that there is nothing wrong with the way I set up the wxColourPickerCtrls. I somehow think there is a difference in the solution properties of the projects. I checked those but was not able to find any relevant differences.
I would really appreciate any hint or help since I am completely stuck on that problem.
Thank you very much in advance and have a good one,
Alex
EDIT:
I attached a screeny of the call stack.
Call stack
When does this code run exactly? If it is done after the library initialization (which would be the case, for example, for any code executed in your overridden wxApp::OnInit()), then wxTheColourDatabase really should be already initialized and what you observe should be impossible, i.e. if it happens it means that something is seriously wrong with your library build (e.g. it doesn't match the compiler options used when compiling your applications).
As always with such "impossible" bugs, starting with a known working code and doing bisection by copying parts of your code into the working version until it stops working will usually end up by finding a bug in your code.
Aside from recompiling rt.jar is there any way I can replace the currentTimeMillis() call with one of my own?
1# The right way to do it is use a Clock object and abstract time.
I know it but we'll be running code developed by an endless number of developers that have not implemented Clock or have made an implementation of their own.
2# Use a mock tool like JMockit to mock that class.
Even though that only works with Hotspot disabled -Xint and we have success using the code bellow it does not "persist" on external libraries. Meaning that you'd have to Mock it everywhere which, as the code is out of our control, is not feasible. All code under main() does return 0 milis (as from the example) but a new DateTime() will return the actual system millis.
#MockClass(realClass = System.class)
public class SystemMock extends MockUp<System> {
// returns 1970-01-01
#Mock public static long currentTimeMillis() { return 0; }
}
3# Re-declare System on start up by using -Xbootclasspath/p (edited)
While possible, and though you can create/alter methods, the one in question is declared as public static native long currentTimeMillis();. You cannot change it's declaration without digging into Sun's proprietary and native code which would make this an exercise of reverse engineering and hardly a stable approach.
All recent SUN JVM crash with the following error:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000, pid=4668, tid=5736
4# Use a custom ClassLoader (new test as suggested on the comments)
While trivial to replace the system CL using -Djava.system.class.loader JVM actually loads up the custom classLoader resorting to the default classLoader and System is not even pushed trough the custom CL.
public class SimpleClassLoader extends ClassLoader {
public SimpleClassLoader(ClassLoader classLoader) {
super(classLoader);
}
#Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
return super.loadClass(name);
}
}
We can see that java.lang.System is loaded from rt.jar using java -verbose:class
Line 15: [Loaded java.lang.System from C:\jdk1.7.0_25\jre\lib\rt.jar]
I'm running out of options.
Is there some approach I'm missing?
You could use an AspectJ compiler/weaver to compile/weave the problematic user code, replacing the calls to java.lang.System.currentTimeMillis() with your own code. The following aspect will just do that:
public aspect CurrentTimeInMillisMethodCallChanger {
long around():
call(public static native long java.lang.System.currentTimeMillis())
&& within(user.code.base.pckg.*) {
return 0; //provide your own implementation returning a long
}
}
I'm not 100% sure if I oversee something here, but you can create your own System class like this:
public static class System {
static PrintStream err = System.err;
static InputStream in = System.in;
static PrintStream out = System.out;
static void arraycopy(Object src, int srcPos, Object dest, int destPos, int length) {
System.arraycopy(src, srcPos, dest, destPos, length);
}
// ... and so on with all methods (currently 26) except `currentTimeMillis()`
static long currentTimeMillis() {
return 4711L; // Your application specific clock value
}
}
than import your own System class in every java file. Reorganize imports in Eclipse should do the trick.
And than all java files should use your applicatikon specific System class.
As I said, not a nice solution because you will need to maintain your System class whenever Java changes the original one. Also you must make sure, that always your class is used.
As discussed in the comments, it is possible that option #3 in the original question has actually worked, successfully replacing the default System class.
If that is true, then application code which calls currentTimeMillis() will be calling the replacement, as expected.
Perhaps unexpectedly, core classes like java.util.Timer would also get the replacement!
If all of the above are true, then the root cause of the crash could be the successful replacement of the System class.
To test, you could instead replace System with a copy that is functionally identical to the original to see if the crashes disappear.
Unfortunately, if this answer turns out to be correct, it would seem that we have a new question. :) It might go like this:
"How do you provide an altered System.currentTimeMillis() to application classes, but leave the default implementation in place for core classes?"
i've tried using javassist to remove the native currentTimeMills, add a pure java one and load it using bootclasspath/p, but i got the same exception access violation as you did. i believe that's probably because of the native method registerNatives that's called in the static block but it's really too much to disassemble the native library.
so, instead of changing the System.currentTimeMills, how about changing the user code? if the user code already compiled (you don't have source code), we can use tools like findbugs to identify the use of currentTimeMillis and reject the code (maybe we can even replace the call to currentTimeMills with your own implementation).
I implemented Aspose.Cells and Aspose.PDF into our companies existing application.
While I had some trouble with this (mostly caused by the fact that I tried to implement both APIs into the exat same file which was a bad idea)
I figured out how to make it work more or less.
My Problem now is while Aspose.Cells works perfectly fine and doesn't seem to have any unusual behavior Aspose.PDF already struggles with setting the license and even when I eventually got this to work I can't even initiate a Aspose::Pdf::Document.
So the first totally unusual thing is the way I had to set the License in the Example code given with the Aspose Package and in the official resources the license is set like this.
auto lic = System::MakeObject<Aspose::Pdf::License>();
lic->SetlLicense("c:\\Foo\fooproj\\Aspose.Total.C++.lic");
This code won't run on my machine and cause the error.
Rough Translation
food.exe triggered a breakpoint
Original
food.exe Hat einen Haltepunkt ausgelöst
The same happens when I initialise a System::String with a emtpy constructor like this.
auto lic = System::MakeObject<Aspose::Pdf::License>();
System::String str;
str.FromUtf8("C:\\foo\fooproj\\Aspose.Total.C++.lic");
lic->SetLicense(str);
BUT if I initialise the System::String with an empty String in the first place setting the license seems to work just fine so this works.
auto lic = System::MakeObject<Aspose::Pdf::License>();
System::String str(u"");
str.FromUtf8("C:\\Projekte\\Aspose\\Lizens\\Aspose.Total.C++.lic");
lic->SetLicense(str);
If this code above works and I try to make an object from Aspose::Pdf::Document this will crash.
void Aspose_pdf::helloWorld()
{
auto doc = System::MakeObject<Aspose::Pdf::Document>();
.....
.....
}
I actually have no idea what's going on. I am not using any using namespace commands at the moment.
Would be greate if someone had an idea how to fix this.
Edit:
The error occures exactly in smart_ptr.h in the following function.
typename std::enable_if<!IsSmartPtr<T>::value, SmartPtr<T> >::type MakeObject(Args&&... args)
{
System::Detail::OwnNextObject ownershipSentry;
T *const object = ::new T(std::forward<Args>(args)...);
ownershipSentry.CreatedSuccessfully(object);
return SmartPtr<T>(object);
}
in the second line so T *const object = ::new T(std::forward<Args>(args)...);
is "causing" the error or atleast here the error will ne triggered.
Edit2:
Here you will find a simple example of how my code looks in general.
I Started with implementing Aspose.Pdf into my Programm so I edited my
Additional Library directories,additional dependencies, additional include directories,preprozessor definitions and my stacksize to fit these settings given in the Aspose.Pdf examples.
After this I created my Aspose_Pdf class and tested it. worked perferctly so far.
After this I made the same edits to fit Aspose.Cells aswell. Also I created a class Aspose_Cells and tested it. While this worked now my Aspose_Pdf class stoped working. After a little time passed I managed to atleast get the License Activation for Aspose_Pdf to work from this point on I had the problems described above.
Additional Dependencies:
...
Aspose.PDF_vc141x64d.lib
aspose_cpp_vc141x64d.lib
Aspose.Cells.lib
Additional Librariedirectories:
...
..\Aspose\Aspose.PDF\lib\Debug
..\Aspose\Aspose.Cells\lib64
additional Includedirectories
...
..\Aspose\Aspose.PDF\lib\Debug
..\Aspose\Aspose.PDF\include\asposecpplib
..\Aspose\Aspose.PDF\include\Aspose.Pdf.Cpp
..\Aspose\Aspose.Cells\Include
..\Aspose\Aspose.Cells\Include\icu\include
..\Aspose\Aspose.Cells\Include\boost
I've never heard about Aspose.Pdf neither I know how does System::MakeObject< work. But for me it looks that all the code might be simplified to next:
Aspose::Pdf::License^ lic = gcnew Aspose::Pdf::License();
System::String^ str = "C:\\foo\\fooproj\\Aspose.Total.C++.lic";
lic->SetLicense(str);
When it comes to Pdf.Document the initialization might look like this:
Aspose::Pdf::Document^ doc = gcnew Aspose::Pdf::Document();
I have some code that compiles fine but I type the closing brace } for the else, it moves all the code from the else { all the way to the left and throws away all indentation.
if (some_condition) {
some_real_code();
} else {
obj.some(stuff);
obj(some,other(stuff));
and when I type the final } I get:
if (some_condition) {
some_real_code();
} else {
obj.
some(stuff);
obj(
some,
other(stuff));
}
The only way I've found to deal with this when it happens is to select a brace in my code, copy it to my clipboard, then do a right-click "paste simple" in clion, which doesn't do any reformatting.
Is there any better way? For example, an a phone, if it autocorrects you and you delete the autocorrected word and retype the same word again, it won't re-autocorrect you because it figures you actually knew what you meant when you do it the second time.
Thank you.
edit: I'm not saying clion is bad or wrong for not understanding my code because in my real code I use language features that it doesn't claim to have support for. I'm just looking for how to work around it's rather aggressive lack of support.
Please, switch off "Reformat block on typing '}'":
Seems that you would be interested in for-IDE-stub implementation in guarded block (Per-ide variable: in CLion it’s CLION_IDE , in AppCode – APPCODE_IDE , in Android Studio – STUDIO_IDE)
I would not turn autoformatting off, because in the majority of cases it is useful. But when this undesired autoformatting happens, I just do the following workaround:
Cancel the autoformatting (Ctrl+Z). The curly bracket is cancelled too.
Instead of typing bare }, I type it commented: //}.
Then just uncomment this line (Ctrl+/ or remove the slashes).
Profit! :)
Currently, I'm working on compiling old .cpp classes under C++ Builder XE. Apart from many troubles, there is one which I have completely no idea how to solve.
My code:
String txt = "<Not so long sql query>";
int licz = some_function(txt, dzeFDS); //1
//assigning licz to somewhere
txt = "<much longer query>";
licz = some_function(txt, budFDS); //2
Problem is that during second call of some_function program is stopped and i have this alert:
First chance exception at $75A1C42D. Exception class EDatabaseError with message 'budFDS: Type mismatch for field 'Function', expecting: String actual: WideString'. Process Call.exe (1896)
It's strange form be, bacause first call of some_function works fine, but this second one (with arguments with the same type) doesn't.
some_function code:
int __fastcall some_function(String txt, TIBDataSet *firDS)
{
firDS->Close();
firDS->SelectSQL->Text = txt;
firDS->Open(); //during debugging, exception occurs in this line
int count = 0;
while(!firDS->Eof)
{ count++;
firDS->Next();
}
return count;
}
Any ideas what why it happens?
Thanks in advance
There is much pain in your future.
Anyway, the problem you're having is with the database connection. There's a field in your database called "Function" that holds a string. This field came across as a String with the ancient database driver that this program originally used. Your shiny, new database driver is telling VCL to expect such things as Unicode, and VCL doesn't like to shove such things into plain Strings, so it expects you to have a WideString ready in which to shove it.
Fortunately, there are ways of beating VCL into submission. What you want to do, since you surely don't want to rewrite half the application by changing TIBDataSet, is to tell the connection not to bother with Unicode. In order to do this, you have to set up the TSQLConnection object with UseUnicode=false, which I hope (I have no way of testing VCL code anymore) should look something like this:
connection->Params->Add("UseUnicode=false");
Where connection is the TSQLConnection object. I think you have to do this before connecting to the database.
If that doesn't work, see if you can configure the database driver to not use Unicode.
Problem solved - this one field Function has other type in C++ Builder design view - it was TStringField, and rest fields has TIBStringField...