Sunday, January 21, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

James Kuyper <jameskuyper@verizon.net>: Jan 21 01:39PM -0500

I know a lot about C++98 in theory, and a little bit about more recent
versions of the language, but have relatively little practical
experience with it: For several years now, one of my responsibilities
has been the maintenance of several C++ programs linked to a set of C++
libraries, poorly designed and no documentation. They're written to
C++2003. I've never had a problem working with this code due to my lack
of C++ experience - all of my problems have been due to the poor design
and the lack of documentation.
However, I've run into a problem that is new to me, and I wasn't sure
how to investigate further. One of these programs aborts under certain
circumstances during an attempt to execute a delete expression.
 
I've checked the obvious: The argument of the delete is the name of a
pointer object that was initialized by a corresponding new-expression.
Execution of the code can't reach the delete-expression without first
passing through the new expression, and it only gets deleted once. That
pointer's non-null value was not changed between the new and delete
expressions. The pointer's value is passed to one subroutine, which
doesn't delete it, either. The object being allocated is an integer
array, so the implicit destructor should be a nop, with no failure modes
of it's own. What else can I check?
 
By analogy with C, which I'm more familiar with, I'd expect a delete
expression to have some relevant similarities to free() in C: the
new-expression needs to store information somewhere about what it
allocated, so the corresponding delete-expression can deallocate it
correctly. For some kinds of code that have undefined behavior, that
undefined behavior might take the form of corrupting the allocation
information - particularly if it's code that writes past the end (or
before the beginning) of other memory also allocated using 'new'. Such
corruption could cause deallocation failure when deleting a completely
unrelated allocation, even if there's nothing wrong with any of the code
involving that other allocation.
Is this in fact the case? Are there any other things that might cause a
delete-expression to fail?
Melzzzzz <Melzzzzz@zzzzz.com>: Jan 21 06:41PM

> doesn't delete it, either. The object being allocated is an integer
> array, so the implicit destructor should be a nop, with no failure modes
> of it's own. What else can I check?
 
Care to show that new/delete in question?
 
--
press any key to continue or any other to quit...
Ian Collins <ian-news@hotmail.com>: Jan 22 08:07AM +1300

On 01/22/2018 07:39 AM, James Kuyper wrote:
> However, I've run into a problem that is new to me, and I wasn't sure
> how to investigate further. One of these programs aborts under certain
> circumstances during an attempt to execute a delete expression.
 
The key is probably how it aborts.
 
Is there an unhandled exception?
 
Is there a memory access violation?
 
Can you trap it in a debugger?
 
> doesn't delete it, either. The object being allocated is an integer
> array, so the implicit destructor should be a nop, with no failure modes
> of it's own. What else can I check?
 
Could it be the old favourite something else corrupting the heap?
Have/can you try running the code under something like valgrind?
 
> involving that other allocation.
> Is this in fact the case? Are there any other things that might cause a
> delete-expression to fail?
 
Not for an array of int.
 
--
Ian.
Gareth Owen <gwowen@gmail.com>: Jan 21 07:30PM

James Kuyper <jameskuyper@verizon.net> writes:
 
Did you check the
 
foo = new int[];
was matched by a
 
delete[] foo;
 
rather than a
 
delete foo;
 
???
 
> unrelated allocation, even if there's nothing wrong with any of the code
> involving that other allocation.
> Is this in fact the case?
 
Yes. 100% yes. Seen it more times than I care to remember
(self-inflicted and otherwise)
 
> Are there any other things that might cause a delete-expression to
> fail?
 
Assuredly, but I'd check the two above first.
James Kuyper <jameskuyper@verizon.net>: Jan 21 02:32PM -0500

On 01/21/2018 02:24 PM, Stefan Ram wrote:
>> of it's own. What else can I check?
 
> I assume you know that there is a special delete operator
> "delete[]" for arrays?
 
Yes. In fact, my group was responsible (though I wasn't involved in the
process at that time) for adding [] where appropriate - the original
code lacked it.
"Öö Tiib" <ootiib@hot.ee>: Jan 21 11:48AM -0800

On Sunday, 21 January 2018 20:39:28 UTC+2, James Kuyper wrote:
> corruption could cause deallocation failure when deleting a completely
> unrelated allocation, even if there's nothing wrong with any of the code
> involving that other allocation.
 
Corrupted memory management information is one of the most probable
reasons of program crashing during delete. Other is delete twice.
Less probable reason is attempt to delete something that wasn't
allocated using new. There are also sometimes mismatch like using new[]
with delete or (new with delete[]) but it does not usually result with
crash.

> Is this in fact the case? Are there any other things that might cause a
> delete-expression to fail?
 
May be. I would just debug it with some special tool for example with
memory sanitizer turned on.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 21 09:59PM +0200

On 21.01.2018 20:39, James Kuyper wrote:
> doesn't delete it, either. The object being allocated is an integer
> array, so the implicit destructor should be a nop, with no failure modes
> of it's own. What else can I check?
 
Looks like memory corruption. If they do things like 'arr = new int[N]'
they might also do things like 'for (int i=0; i<=N; ++i) arr[i] = 42;'.
Note that this needs to be done not to the 'arr', but to the allocation
before arr in memory so that the memory manager control block for arr
gets corrupted.
 
The correct C++ way is of course to use:
 
std::vector<int> arr(N, 42);
 
or
 
std::vector<int> arr(N);
std::fill(arr.begin(), arr.end(), 42)
 
or
 
std::vector<int> arr(N);
for (auto& ref: arr) {
ref = 42;
}
 
which all are much better in avoiding buffer overrun errors.
 
hth
Paavo
James Kuyper <jameskuyper@verizon.net>: Jan 21 03:27PM -0500

On 01/21/2018 02:07 PM, Ian Collins wrote:
>> how to investigate further. One of these programs aborts under certain
>> circumstances during an attempt to execute a delete expression.
 
> The key is probably how it aborts.
 
It exits with a unix status of 34304=0x8600, indicating abnormal
termination by signal number of 6, which is SIGABRT. When I said
"abort", I was being very specific.
 
> Is there an unhandled exception?
 
> Is there a memory access violation?
 
There's no indication of either possibility.
 
> Can you trap it in a debugger?
 
I'm just starting to investigate this problem, and am learning things
about the program that I hadn't previously needed to know since becoming
responsible for it. It's run from a complicated script that sets up it's
running environment, and I haven't yet figured out how to set up the
environment so I can run it on it's own. I may just create a modified
version of the script to run it inside the debugger.
 
>> array, so the implicit destructor should be a nop, with no failure modes
>> of it's own. What else can I check?
 
> Could it be the old favourite something else corrupting the heap?
 
That's what I'm assuming, by analogy with C, even though I know that
new/delete don't have any necessary connection with malloc() and free().
That's what I was implying in more generic form when talking about
writing past the end or before the beginning of a block of allocated
memory. I'm not looking forward to another heap corruption hunt through
unfamiliar code.
 
> Have/can you try running the code under something like valgrind?
 
I may have to - but my prior experience with valgrind suggests that it
produces too much information to make it easy to find the particular
issue that's actually causing a problem, particularly on poorly written
code like this.
James Kuyper <jameskuyper@verizon.net>: Jan 21 03:36PM -0500

On 01/21/2018 02:59 PM, Paavo Helde wrote:
> ref = 42;
> }
 
> which all are much better in avoiding buffer overrun errors.
 
You know that, I know that, but the authors of this code were apparently
more C-bound than you or me. The part of the code i'm looking at has no
containers, no iterators, no algorithms. Just lots of C-style arrays,
pointers, and arrays. Other parts of the code make heavy use of
C++-specific language features, which is the kind of thing you get when
code has multiple authors.
 
I've thought of "fixing" this problem by doing such a re-write, but it
would take a lot of time, and I was hoping that a more focused approach
to debugging it would be possible.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 21 07:24PM

>doesn't delete it, either. The object being allocated is an integer
>array, so the implicit destructor should be a nop, with no failure modes
>of it's own. What else can I check?
 
I assume you know that there is a special delete operator
"delete[]" for arrays?
ram@zedat.fu-berlin.de (Stefan Ram): Jan 21 08:01PM

>Yes. In fact, my group was responsible (though I wasn't involved in the
>process at that time) for adding [] where appropriate - the original
>code lacked it.
 
You said you already checked all of this. But since I have
no better idea, I wrote an attempt at a tracingnew and
tracingdelete below, that can be used as a substitute for
"new" and "delete" but will check for some common types of
errors. You can add more checks of you own.
 
main.cpp
 
#include <initializer_list>
#include <new>
#include <iostream>
#include <ostream>
#include <cstdlib>
#include <unordered_set>
#include <string>
 
::std::unordered_set< void * >set;
 
static inline bool address_already_in_set( void * const address )
{ return set.find( address ) != set.end(); }
 
static inline void add_address_to_set( void * const address )
{ if( !address )
{ ::std::cerr << "address is zero on allocate.\n"; ::std::abort(); }
if( address_already_in_set( address ))
{ ::std::cerr << "address_already_in_set( address )\n"; ::std::abort(); }
set.insert( address ); }
 
static inline void remove_address_from_set( void * const address )
{ if( !address )
{ ::std::cerr << "address is zero on delete.\n"; ::std::abort(); }
if( !address_already_in_set( address ))
{ ::std::cerr << "address not in set on delete.\n"; ::std::abort(); }
set.erase( address ); }
 
template< typename T >
void add( T * const pointer )
{ void * const address =( void * )pointer;
if( address_already_in_set( address ))
{ ::std::cerr << "address_already_in_set( address )\n"; ::std::abort(); }
else
{ add_address_to_set( address ); }}
 
template< typename T >
void remove( T * const pointer )
{ void * const address =( void * )pointer;
remove_address_from_set( address ); }
 
template< typename T, typename... Ts >
inline T* tracingnew( Ts && ... params )
{ T* result = new T( ::std::forward< Ts >( params )... );
add( result );
return result; }
 
template< typename T >
inline void tracingdelete( T * const pointer )
{ remove( pointer );
delete pointer; }
 
int main()
{ /* usage example */
 
int * p = tracingnew< int >();
tracingdelete( p );
::std::cerr << "ok.\n";
 
tracingdelete( p ); }
 
transcript
 
ok.
address not in set on delete.
 
This application has requested the Runtime to terminate it in an unusual way.
 
One should replace all "new" and "delete" by the tracing versions
(Disclaimer: I make no guarantees as to the quality of my code).
 
Later, one can change the implementations to something like
 
template< typename T, typename... Ts >
inline T* tracingnew( Ts && ... params )
{ T* result = new T( ::std::forward< Ts >( params )... );
return result; }
 
template< typename T >
inline void tracingdelete( T * const pointer )
{ delete pointer; }
 
Which hopefully should behave just like the normal "new"
and "delete", so that the program will run as fast as ever.
(This is the theory, I have not tested all of this.)
ram@zedat.fu-berlin.de (Stefan Ram): Jan 21 08:10PM

>You can add more checks of you own.
 
(Not related to the unexplainable aborts:)
 
Especially, one can dump the set at the end of the
program to see any memory that is still allocated.
 
One also can allocate some memory before and after the
client memory and write the value "85" to it. Then
- on deallocation - on can check that the 85 is still
there to detect some buffer overruns.
Christian Gollwitzer <auriocus@gmx.de>: Jan 21 08:09AM +0100

Am 20.01.18 um 23:05 schrieb Rick C. Hodgin:
 
> Have you ever considered the possibility that my posts aren't as you
> indicate? That maybe they offer you more than you realize today,
> making them not negative, but rather something most desirable?
 
BUY A NEW CAR! BEST GERMAN CARS FOR REASONABLE PRICES! LONG ENDURANCE,
LOW CONSUMPTION!
That maybe offers you more than you realize today, as soon as your old
car breaks and the gas prizes go up, making this not negative spam, but
rather something most desirable?
 
Now consider me posting this over and over with different words, going
on about how you should not drive a car at all, but rather ride on a
bicycle, and go vegan to save the planet.... Even if this is _most
desirable_, it simply has no place in this group because it is *off-topic*.
 
Christian
Mel <mel@zzzzz.com>: Jan 21 09:20AM +0100

On Sun, 21 Jan 2018 08:09:40 +0100, Christian Gollwitzer
> Am 20.01.18 um 23:05 schrieb Rick C. Hodgin:
> > On Saturday, January 20, 2018 at 4:50:41 PM UTC-5, Mr Flibble
wrote:
> >> On 20/01/2018 21:32, Rick C. Hodgin wrote:
 
> >>> You can keep posting all your hate toward me, Leigh. I will
continue
> >>> to post about Jesus Christ. Consider your actions and future
in so
> >>> doing. Your way comes with too heavy a price, one you'll be
unable to
> >>> pay.
 
> >> There is no hatred, just irritation that you refuse to stop
spamming
> >> this technical newsgroup with your religious nonsense.
 
> > Have you ever considered the possibility that my posts aren't as
you
> > indicate? That maybe they offer you more than you realize today,
> > making them not negative, but rather something most desirable?
 
> BUY A NEW CAR! BEST GERMAN CARS FOR REASONABLE PRICES! LONG
ENDURANCE,
> LOW CONSUMPTION!
> That maybe offers you more than you realize today, as soon as your
old
> car breaks and the gas prizes go up, making this not negative spam,
but
> rather something most desirable?
 
 
> Now consider me posting this over and over with different words,
going
> on about how you should not drive a car at all, but rather ride on
a
> bicycle, and go vegan to save the planet.... Even if this is _most
> desirable_, it simply has no place in this group because it is
*off-topic*.
Repeating same nonsense all over again is hallmark of lunacy...
 
 
--
Press any key to continue or any other to quit
David Brown <david.brown@hesbynett.no>: Jan 21 01:25PM +0100

On 20/01/18 22:50, Mr Flibble wrote:
 
> There is no hatred, just irritation that you refuse to stop spamming
> this technical newsgroup with your religious nonsense.
 
> /Flibble
 
Rick has promised to use a [Jesus Loves You] tag in all the religious
threads he starts. How about if you, Mr. Flibble, tag threads like this
with [We hate religious spam] ? Then we can all set up filters for your
impersonation threads. I disagree with Rick on most things, and wish he
would stop his religious postings - but I find your imitation postings
much more offensive and annoying, and it is absolutely clear to everyone
that you encourage more of them. Your behaviour here is as childish,
idiotic and counter-productive as Brian's complaints about swearing.
David Brown <david.brown@hesbynett.no>: Jan 21 01:31PM +0100

On 20/01/18 23:18, Mr Flibble wrote:
>> proselytising, you would be asked to leave.  If you refused, you would
>> be shown the door.  Unfortunately Usenet doesn't have a door...
 
> +1
 
If you started imitating people and provoking proselytising in a
programmer's meeting, you'd be asked to leave too - even if you are one
of the key speakers with an impressive gui library to discuss.
 
Please think about what you are doing with posts like the start of this
thread, Mr. Flibble. I fully agree with your desire of stopping
religious proselytising - I totally disagree with your methods here that
are a "cure" worse than the disease.
bartc <bc@freeuk.com>: Jan 21 03:30PM

On 20/01/2018 22:16, Ian Collins wrote:
 
> If you walked into a programmer's meeting and started your
> proselytising, you would be asked to leave.  If you refused, you would
> be shown the door.  Unfortunately Usenet doesn't have a door...
 
This isn't a programmer's meeting on private property. This is more like
a corner of a public square where programmers hang out.
 
 
--
bartc
Gareth Owen <gwowen@gmail.com>: Jan 21 07:25PM

>> If you'd like to see spam from Leigh Johnston stop impacting this
>> group
 
> Your lack of any sense of irony is astonishing.
 
No its not.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 21 05:12PM

The Church of the Flying Spaghetti Monster, after having existed in
secrecy for hundreds of years, came into the mainstream just a few years
ago*.
 
With millions, if not thousands, of devout worshipers, the Church of the
FSM is widely considered a legitimate religion, even by its opponents –
mostly fundamentalist Christians, who have accepted that our God has
larger balls than theirs.
 
Some claim that the church is purely a thought experiment or satire,
illustrating that Intelligent Design is not science, just a
pseudoscience manufactured by Christians to push Creationism into public
schools. These people are mistaken — The Church of FSM is legit, and
backed by hard science. Anything that comes across as humor or satire is
purely coincidental. #atheism
 
--
 
Thank you,
Rick C. Hodgin
guinness.tony@gmail.com: Jan 21 10:52AM -0800

On Sunday, 21 January 2018 17:12:46 UTC, Rick C. Hodgin wrote:
> schools. These people are mistaken — The Church of FSM is legit, and
> backed by hard science. Anything that comes across as humor or satire is
> purely coincidental. #atheism
 
Ramen, brother.
 
May you be touched by his noodle appendage.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 21 05:24AM -0800

This post describes the life timeline of each person on Earth. People are
divided into two camps: saved, unsaved. This relates whether or not a
person receives forgiveness from Jesus Christ for their sin ... or not.
 
When a person is born:
 
You are ALREADY dead in sin. You ONLY know what your flesh feeds you. We
are more than our flesh. Eternal life is life of the spirit, not the flesh,
and because of sin we have ALREADY been judged and are no longer alive in
our spirit.
 
Below is the life cycle of each of us, for we are more than this flesh, and
we continue on after we leave this world:
 
Eventual Believer Non-believer
--------------------------------------- ---------------------------------
FLESH SPIRIT == FLESH SPIRIT
===== ====== == ===== ======
| (dead) == | (dead)
| || == | ||
(born) | (dead) == (born) | (dead)
|| | || == || | ||
(grow) | (dead) == (grow) | (dead)
|| | || == || | ||
+-------------------------------------+ == || | (dead)
| (accepts Christ as (born again) | == || | ||
| Savior and Lord) (alive) | == || | (dead)
| || || | == || | ||
| (live, work) (alive) | == (live, work) | (dead)
| || || | == || | ||
| (age) (alive) | == (age) | (dead)
| || || | == || | ||
| (die) (alive) | == (die) | (dead)
| || | == || | ||
| Note: Once the (rewards) | == (sleep) | (dead)
| believer accepts || | == | ||
| forgiveness of (alive with | == | (judgment)
| their sin, then God forever)| == | ||
| the flesh and || | == | (cast into
| the spirit are (Heaven) | == | Hell forever)
| one in the new || | == | ||
| believer's life. (alive) | == | (torment)
| || | == | ||
| God's Holy Spirit (joy) | == | (death)
| guides us in our || | == | ||
| flesh / natural (alive) | == | (torment)
| life, as a down || | == | ||
| payment of the (peace) | == | (death)
| full live we || | == | ||
| receive in His (alive) | == | (torment)
| Kingdom in all || | == | ||
| of eternity. (happiness) | == | (death)
| || | == | ||
| (alive) | == | (torment)
| || | == | ||
| (learning) | == | (death)
| || | == | ||
| (alive) | == | (torment)
| || | == | ||
| (growing) | == | (death)
| || | == | ||
| (alive) | == | (torment)
| || | == | ||
+-------------------------------------+ ---------------------------------

And it goes on. For those alive with Christ, exploring the universe,
learning ever more about His Kingdom. How much is there to know? How
deep is an infinite God? How vast is the Kingdom He's created here for
us to explore?
 
I would save people from that quick end of being cast into Hell and being
tormented forever, by teaching them to come to Jesus Christ and ask for
forgiveness for their sin.
 
You do have sin.
You do need forgiveness.
Jesus is ready to forgive you.
Ask Him to forgive you and make your spirit alive forever.
 
For those who are only born once (of the flesh), you will die twice
(once of the flesh, once of the spirit). But for those who are born
twice (once of the flesh, once of the spirit), you will only die once.
 
Both will receive an eternal body after we leave this world. But the
one who dies with their sin remaining charged to them will be cast into
Hell, because they never came to accept the truth, never came to accept
that Jesus Christ is truth, that He cleanses us from all unrighteousness.
 
Your eternal fate depends ENTIRELY upon what YOU do with Jesus Christ.
Ignore Him or accept His free offer of salvation ... the choice is yours.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 21 02:47AM -0800

I, the real Rick C. Hodgin, did not write the obscene posts
ahead of this reply.
 
Examine the message headers to see who writes each post that
seems outwardly to come from me.
 
I am being impersonated by an online identity thief, one being
enabled by GigaNews who would not act when violations of
their publicly posted acceptable use policy were reported.
The Texas Attorney General also would not act stating that
GigaNews was not breaking any laws, but only violating their
own stated public policy, apparently not an act of fraud in
Texas.
 
Please pray for Leigh Johnston, who is the impersonator.
And please pray for the folks at GigaNews.
 
--
Rick C. Hodgin
"Öö Tiib" <ootiib@hot.ee>: Jan 21 04:40AM -0800

On Sunday, 21 January 2018 12:48:11 UTC+2, Rick C. Hodgin wrote:
> I, the real Rick C. Hodgin, did not write the obscene posts
> ahead of this reply.
 
How does it relate to C++? We all know that you and your fans and
impersonators want to annoy and irritate each other and people.
It does not work. We don't read it, it is boring and silly and you
even refuse to discuss that anyway.
 
Yes, lot of us are law-abiding citizens. But if lawyer said that
no laws were broken by GigaNews with that garbage of yours then so it
is. We have no skills to help there and most have other crucial
and less impossible things to do, books to read, friends to attend,
works to finish and kids to raise.
 
So ... "As you sow so will you reap." Cicero
Alexander Huszagh <ahuszagh@gmail.com>: Jan 20 03:50PM -0800

Think about how far frameworks like Qt took to develop, and how far from polished they are. Qt is excellent, a work in progress, and a massive company is required to develop and maintain it. In addition, the virtual interfaces and lack of custom allocators would be a strict no in the C++ standard library, yet is the closest implementation we have to a working, cross-platform, C++ GUI framework that is clean and performant.
 
I would like unicorns, but I doubt I will get them.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 21 12:11AM

On 20/01/2018 23:50, Alexander Huszagh wrote:
> Think about how far frameworks like Qt took to develop, and how far from polished they are. Qt is excellent, a work in progress, and a massive company is required to develop and maintain it. In addition, the virtual interfaces and lack of custom allocators would be a strict no in the C++ standard library, yet is the closest implementation we have to a working, cross-platform, C++ GUI framework that is clean and performant.
 
> I would like unicorns, but I doubt I will get them.
 
My GUI library, neoGFX, may meet your requirements:
 
http://neogfx.org
 
The intention is for neoGFX is be a better quality and cheaper
alternative to the bloated, baggage ridden antiquated Qt.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)