Initializing wxCharBuff in call to wxFileConfig Topic is solved

[dowty]

I am having trouble with initialization of wxFileConfig under wxGTK Linux (Fedora 2.4). I am updating from wxWidgets 2.4 to 2.8.7. There was no problem in 2.4.

When initializing, reading a large existing configuration file, I get a fatal segmentation fault.

fileconf.cpp:479 points eventually to:

wxTextFile::OnRead - textfile.cpp:121:

if ( !buf.extend(bufSize - 1 /* it adds 1 internally */) )

this bombs in buffer.h: 127:

DEFINE_BUFFER(wxCharBuffer, char, wxStrdupA);

the actual bomb is in realloc() in libc.so.6

I tried initializing wxCharBuffer buf in wxTextFile::OnRead to a large size, but then the bomb is from this initialization, pointing to the same line in buffer.h and to malloc().

The configuration file I am reading is length 8951, maybe longer than a configuration file is supposed to be, and if the file is smaller there is no problem. There is no problem if the file doesn't exist, as wxTextFile::OnRead is not called. The file is then created and written to successfully.

[dowty]

Further info:

my preferred creation is:

gl_config = new wxFileConfig(wxgen.apptit,wxEmptyString,
wxEmptyString,wxEmptyString,wxCONFIG_USE_LOCAL_FILE);

with wx/fileconf.h, but I also tried:

gl_config = new wxConfig(wxgen.apptit);

with wx/config.h

The above works not only with wxGTK 2.4, but also Windows and Mac. Also I built the conftest sample, and bulked up the configuration file it generated to way over 10k, and there was no problem rereading it.

[DavidHart]

Hi Eric,

That's strange. While there have been a one or two changes between 2.4.2 and 2.8.7 , it's an odd place to crash.

The configuration file I am reading is length 8951, maybe longer than a configuration file is supposed to be

No. My app has a 39k config file, and the same file works perfectly well both in 2.4.2 ansi and 2.8.7 unicode builds.

There is no problem if the file doesn't exist, as wxTextFile::OnRead is not called. The file is then created and written to successfully.

And if you then close the app and rerun using the new config file, does the crash still happen?

I wonder if there is one particular entry that's causing the problem (and perhaps only in a unicode build?). I suggest you ask your debugger which entry it's processing when it crashes, or else use e.g. a wxLogDebug statement similarly.

Regards,

David

[ArKay]

The problem could be somewhere else entirely, maybe code which gets executed before messes up memory so that the realloc() here finally crashes.

I would check other places as well

[dowty]

I moved the initialization of wxFileConfig to the very beginning of MyApp::OnInit() and this solved the problem. Apparently, as ArKay said, something that was done in the fairly small amount of code before the original initialization was screwing up some part of wxCharBuffer (or something). I suspect that this was in a wxWidgets function specific to V2.8 (and maybe GTK), since the code works fine in other situations, and nothing else is screwed up after the move. (I have not upgraded Windows and Mac versions yet to V2.8 - I will know more when I do).

Anyway, I will not pursue this any further now, but if someone want to debug I can provide information on what was originally called.

[IB-Mulka]

Hi all,
I'm running in the some problem.

wxFileConfig made a stack corruption while extensive periodic file access. The reason is the call of "Free()" for the internal object of variable "buf". The stack corruption is made in line 182. The line must be changed from:

Code: Select all

free(buf.release());

to:

Code: Select all

// we don't need this memory any more, but for compatibility
// we should use the internal memory de-allocator of wxCharBuffer
buf.reset();

In addition the atteched file is optimized for seekable files, because for seekable files the processing can be speedup by using direct File-Read() to "buf" without an extra memcpy().

Best regards
Sven

[DavidHart]

Hi Sven,

This is a user forum, and isn't followed by many devs. I suggest you either post to the wx-dev mailing list, or submit your changes as a patch to http://sourceforge.net/tracker/?group_i ... tid=309863

Regards,

David

[IB-Mulka]

Hello David,

thanks for your hints. I have posted my changes as two patch (1935968 and 1935975). The first describes the bug and the second the optimization. Sorry it wars my first patch.

Best regards
Sven

[IB-Mulka]

Hi all,

I am sorry because I must cancel my patch. I have played something arround my stack corruption. After re-compiling of all I have no stack corruption anymore. The reason must be in the incremental compile/linking process of VC8.

The wxTextFile works fine but it can optimized something, show for patch 1935975 http://sourceforge.net/tracker/index.ph ... tid=309863

Best regards
Sven