help with dirty hack

[Nmx]

Hi everyone,

I'm writing a patch to a search engine (aspseek
http://www.aspseek.org/) compile under gcc 3.4.4 on FC3.

At some point, I found this piece of code:

--
// Dirty hack to avoid non-threadsafeness of string class
// We set ref to big value here so it will not reach 0
// Works only with GNU libstdc++ STL!
static long* ref = (long*)config_name.data() - 2;
*ref = 0x40000000;
--

I don't have a clue of this do except for a really bad side effect: if
I change the value of any std::string initialized as an empty string
then every string initialized by the same way has his value modified.
If I strip out this piece of code then the side effect disappear.

Does anyone have a clue of what this code really do?

Thanks in advanced,

nmx

[Victor Bazarov]

Nmx wrote:

I'm writing a patch to a search engine (aspseek
http://www.aspseek.org/) compile under gcc 3.4.4 on FC3.

At some point, I found this piece of code:

--

Please do not use the two-dashes-on-a-line as your formatting element.
It's actually a standard separator for the signature, and many news (and
e-mail) programs remove everything below it when quoting. Now I am forced
to manually re-quote your text...

// Dirty hack to avoid non-threadsafeness of string class
// We set ref to big value here so it will not reach 0
// Works only with GNU libstdc++ STL!
static long* ref = (long*)config_name.data() - 2;
*ref = 0x40000000;
--

I don't have a clue of this do except for a really bad side effect: if
I change the value of any std::string initialized as an empty string
then every string initialized by the same way has his value modified.
If I strip out this piece of code then the side effect disappear.

Does anyone have a clue of what this code really do?

If 'config_name' is an object of type 'std::string', then this hack
seems to rely on the implementation of the class that stores the *ref*
*count* two longs before the memory location of the buffer. Setting
the ref count to 4 * 2^28 helps to keep it alive or protect from any
reallocation, (maybe?) I have no real idea. You might want to consult
with GNU folks.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

Nmx wrote:

// Dirty hack to avoid non-threadsafeness of string class
// We set ref to big value here so it will not reach 0
// Works only with GNU libstdc++ STL!
static long* ref = (long*)config_name.data() - 2;
*ref = 0x40000000;
--

I don't have a clue of this do except for a really bad side effect: if
I change the value of any std::string initialized as an empty string
then every string initialized by the same way has his value modified.
If I strip out this piece of code then the side effect disappear.

Does anyone have a clue of what this code really do?

Nobody answered in an hour, so I will provide the generic answer:

Take it out, and carefully review the rest of the code. Someone capable of
commenting such a diseased piece of code as a mild "hack" is capable of
writing anything and not commenting it.

The hack appears to reach into the secret shared string that's inside many
std::string representations. It sets the reference count to a huge number,
allowing the referred-to string data to leak. That, in turn, lets other
threads read the leaked data after its owning thread has destroyed it.

I don't know why this would affect other strings. The hack might have once
worked "better" than it does now. Your compiler, your input libraries, even
your linker settings may have changed since the hack worked. The symptom you
report might change if you compile a different way.

You need to perform the tiny bit of research that your predecessor deferred.
Find a forum that discusses the thread package this program uses, and ask it
how to pass a string between two threads. They will help you write something
simple and robust.

Whatever the problems of this hack, you might get problems if you take it
out. The other thread might access the string after this thread destroys it.

In general, you must maintain this code's value without increasing your
burden of debugging it. Read /Working Effectively with Legacy Code/ by Mike
Feathers to learn to do that.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Nmx]

Victor,

Please do not use the two-dashes-on-a-line as your formatting element.
It's actually a standard separator for the signature, and many news (and
e-mail) programs remove everything below it when quoting. Now I am forced
to manually re-quote your text...

I didn't realize. Sorry for that...

If 'config_name' is an object of type 'std::string', then this hack
seems to rely on the implementation of the class that stores the *ref*
*count* two longs before the memory location of the buffer. Setting
the ref count to 4 * 2^28 helps to keep it alive or protect from any
reallocation, (maybe?) I have no real idea. You might want to consult
with GNU folks.

Thanks for your reply.

Actually yes, config_name is a std::string object. I will check this
with GNU guys. By the way, do you know how this can help with
threadsafeness of string class?

Thanks again,

nmx
Victor Bazarov wrote:

Nmx wrote:

I'm writing a patch to a search engine (aspseek
http://www.aspseek.org/) compile under gcc 3.4.4 on FC3.

At some point, I found this piece of code:

--

Please do not use the two-dashes-on-a-line as your formatting element.
It's actually a standard separator for the signature, and many news (and
e-mail) programs remove everything below it when quoting. Now I am forced
to manually re-quote your text...

// Dirty hack to avoid non-threadsafeness of string class
// We set ref to big value here so it will not reach 0
// Works only with GNU libstdc++ STL!
static long* ref = (long*)config_name.data() - 2;
*ref = 0x40000000;
--

I don't have a clue of this do except for a really bad side effect: if
I change the value of any std::string initialized as an empty string
then every string initialized by the same way has his value modified.
If I strip out this piece of code then the side effect disappear.

Does anyone have a clue of what this code really do?

If 'config_name' is an object of type 'std::string', then this hack
seems to rely on the implementation of the class that stores the *ref*
*count* two longs before the memory location of the buffer. Setting
the ref count to 4 * 2^28 helps to keep it alive or protect from any
reallocation, (maybe?) I have no real idea. You might want to consult
with GNU folks.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

Actually yes, config_name is a std::string object. I will check this

with GNU guys. By the way, do you know how this can help with
threadsafeness of string class?

nmx

Please read my post.

Nmx wrote:

Victor,

>Please do not use the two-dashes-on-a-line as your formatting element.
It's actually a standard separator for the signature, and many news (and
e-mail) programs remove everything below it when quoting. Now I am
forced
to manually re-quote your text...

I didn't realize. Sorry for that...

The standard separator for the signature is "-- \n", with a space:

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Nmx]

Thanks for your explanation, Phlip.

I don't know why this would affect other strings. The hack might have once
worked "better" than it does now. Your compiler, your input libraries, even
your linker settings may have changed since the hack worked. The symptom you
report might change if you compile a different way.

Actually this program was originally intend to compile under gcc 2.9
I'm trying to make it work on gcc 3.4.

Thanks again and I'll spend some time reading that book.

nmx
Phlip wrote:

Nmx wrote:

// Dirty hack to avoid non-threadsafeness of string class
// We set ref to big value here so it will not reach 0
// Works only with GNU libstdc++ STL!
static long* ref = (long*)config_name.data() - 2;
*ref = 0x40000000;
--

I don't have a clue of this do except for a really bad side effect: if
I change the value of any std::string initialized as an empty string
then every string initialized by the same way has his value modified.
If I strip out this piece of code then the side effect disappear.

Does anyone have a clue of what this code really do?

Nobody answered in an hour, so I will provide the generic answer:

Take it out, and carefully review the rest of the code. Someone capable of
commenting such a diseased piece of code as a mild "hack" is capable of
writing anything and not commenting it.

The hack appears to reach into the secret shared string that's inside many
std::string representations. It sets the reference count to a huge number,
allowing the referred-to string data to leak. That, in turn, lets other
threads read the leaked data after its owning thread has destroyed it.

I don't know why this would affect other strings. The hack might have once
worked "better" than it does now. Your compiler, your input libraries, even
your linker settings may have changed since the hack worked. The symptom you
report might change if you compile a different way.

You need to perform the tiny bit of research that your predecessor deferred.
Find a forum that discusses the thread package this program uses, and ask it
how to pass a string between two threads. They will help you write something
simple and robust.

Whatever the problems of this hack, you might get problems if you take it
out. The other thread might access the string after this thread destroys it.

In general, you must maintain this code's value without increasing your
burden of debugging it. Read /Working Effectively with Legacy Code/ by Mike
Feathers to learn to do that.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!