Summary: Indirect variable parameters sometimes cause
segmentation fault
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu
--- Comment #1 from rogerio at rilhas dot com 2010-08-10 22:03 ---
Created an attachment (id=21448)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21448&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #2 from rogerio at rilhas dot com 2010-08-10 22:03 ---
Created an attachment (id=21449)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21449&action=view)
Source file with comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #3 from rogerio at rilhas dot com 2010-08-10 22:04 ---
Created an attachment (id=21450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21450&action=view)
Compilation script (for the working and non-working builds)
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #5 from rogerio at rilhas dot com 2010-08-10 22:33 ---
Are you sure this is the way to resolve this issue? I think this will make GCC
an inferior product, as all other compilers I've tested produce correct
results. As GCC sometimes produces correct code (and in such cas
--- Comment #6 from rogerio at rilhas dot com 2010-08-10 22:35 ---
Let me just add: if you can tell me what options to set to make it always work
that would already be helpful. I noticed that disabling optimizations helps,
but not everytime (adding a lot of local automatic variables to
--- Comment #8 from rogerio at rilhas dot com 2010-08-11 00:54 ---
I think you are wrong, I'm not depending on undefined behaviour. When I request
&format that is clearly defined: I should be getting the address of the format
pointer as placed on the stack. Just like I w
--- Comment #10 from rogerio at rilhas dot com 2010-08-11 01:57 ---
I'm replying now not in the context of the bug (since as I mentioned I must
move on), but just as a conversation between 2 persons. So please don't getting
me wrong for insisting.
The cdecl calling convention
--- Comment #12 from rogerio at rilhas dot com 2010-08-11 11:20 ---
Created an attachment (id=21452)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21452&action=view)
Preprocessed file (with example 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #13 from rogerio at rilhas dot com 2010-08-11 11:21 ---
Created an attachment (id=21453)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21453&action=view)
Source file (example 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #14 from rogerio at rilhas dot com 2010-08-11 11:22 ---
No, you are not correct. The equivalent code to what I'm doing would be
something like:
int buffer[4]; // 16 bytes on stack
buffer[0]=(int)&format
buffer[1]=(int)10
buffer[2]=(int)&another_string
buffer[3]
--- Comment #18 from rogerio at rilhas dot com 2010-08-11 13:11 ---
Of course vsnprintf was my first choice, as you can see from the WIN32 part of
the code I sent you. In WIN32 I can use vsnprint in a very natural and
predictable way in "format_indirect". In LINUX this cannot
--- Comment #21 from rogerio at rilhas dot com 2010-08-11 17:04 ---
Subject: Re: Indirect variable parameters sometimes cause
segmentation fault
Yes, I was using that solution up to 2003, but then I stopped
using it in favour of the more confortable &format (the one I
showed
--- Comment #22 from rogerio at rilhas dot com 2010-08-11 17:15 ---
(In reply to comment #19)
> (In reply to comment #18)
> > Of course vsnprintf was my first choice, as you can see from the WIN32 part
> > of
> > the code I sent you. In WIN32 I can use vsnprint
--- Comment #25 from rogerio at rilhas dot com 2010-08-11 19:51 ---
(In reply to comment #24)
> (In reply to comment #22)
> >
> > If GCC supports cdecl on a x86 plaform then it must support the packing of
> > parameters as defined for x86 (it is not standardize t
--- Comment #27 from rogerio at rilhas dot com 2010-08-11 20:04 ---
(In reply to comment #26)
> >This code does not compile in GCC, and so is not portable.
> No it is not portable because that code is just plain invalid; though MS
> accepts it as it is implementing some
--- Comment #28 from rogerio at rilhas dot com 2010-08-11 20:07 ---
(In reply to comment #23)
> First off I already mentioned what is undefined in this example in comment
> #11.
> The part of the standard that mentions about arrays. And how the address of
> a
> scala
--- Comment #30 from rogerio at rilhas dot com 2010-08-11 20:58 ---
Really? Your comment #11 has so many mistakes in it that maybe you are the one
who should learn a little bit more on C.
>The ABI is not of concern here really. The issue comes down to you have:
>char *a;
>
--- Comment #32 from rogerio at rilhas dot com 2010-08-11 21:12 ---
(In reply to comment #31)
> >Didn't you understand the equivalent code would be:
> No, as the variables act the same if they are automatic variables or
> arguments.
> there is no different betwee
--- Comment #35 from rogerio at rilhas dot com 2010-08-11 22:16 ---
(In reply to comment #33)
> Yes GCC implements that ABI and &argument will get you the address of that
> argument.
If that is so then the format parameter will be placed at some address X, param
1 at address
--- Comment #38 from rogerio at rilhas dot com 2010-08-11 22:35 ---
(In reply to comment #34)
> (In reply to comment #25)
> > In other words my code is not portable because GCC is not doing what it
> > should.
> > GCC causes code not to be portable a lot of times,
--- Comment #39 from rogerio at rilhas dot com 2010-08-11 22:37 ---
(In reply to comment #37)
> Btw, 6.5.6/7 "For the purposes of these operators, a pointer to an object that
> is
> not an element of an array behaves the same as a pointer to the first element
> of an ar
--- Comment #41 from rogerio at rilhas dot com 2010-08-11 22:50 ---
> It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
--- Comment #42 from rogerio at rilhas dot com 2010-08-11 22:51 ---
> It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
--- Comment #43 from rogerio at rilhas dot com 2010-08-11 22:52 ---
> It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
--- Comment #44 from rogerio at rilhas dot com 2010-08-11 22:53 ---
(In reply to comment #36)
> (In reply to comment #35)
> > (In reply to comment #33)
> It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entri
--- Comment #45 from rogerio at rilhas dot com 2010-08-11 22:54 ---
(In reply to comment #43)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #46 from rogerio at rilhas dot com 2010-08-11 22:54 ---
(In reply to comment #42)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #47 from rogerio at rilhas dot com 2010-08-11 22:55 ---
(In reply to comment #41)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #49 from rogerio at rilhas dot com 2010-08-11 23:22 ---
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #37)
> Why do you think GCC makes it the address of a copy?
Well, the first observation was dumpung the memory around the retu
--- Comment #50 from rogerio at rilhas dot com 2010-08-11 23:43 ---
(In reply to comment #48)
> >No, cdecl states that &x+1==&y, and that &x+2==&z.
> Maybe the ABI says that but that does not mean you can access "&x + 1" to get
> to &y at l
--- Comment #51 from rogerio at rilhas dot com 2010-08-12 02:08 ---
Given all that we have established in our conversation I think I can now
demonstrate the bug easily.
The entry to the "format_direct" call (in the main function, just before
entering the "format_d
--- Comment #52 from rogerio at rilhas dot com 2010-08-12 02:09 ---
Created an attachment (id=21462)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21462&action=view)
Snapshot 1 - Breakpoint before calling "format_direct"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #53 from rogerio at rilhas dot com 2010-08-12 02:10 ---
Created an attachment (id=21463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21463&action=view)
Snapshot 2 - Inside "format_direct" to show cdecl ABI parameter packing
--
http://gcc
--- Comment #54 from rogerio at rilhas dot com 2010-08-12 02:12 ---
Created an attachment (id=21464)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21464&action=view)
Snapshot 3 - Breakpoint before calling "format_indirect" (showing dump for
$ebp+0x10)
--
h
--- Comment #55 from rogerio at rilhas dot com 2010-08-12 02:12 ---
Created an attachment (id=21465)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21465&action=view)
Snapshot 4 - Showing incorrect value for PTR4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #57 from rogerio at rilhas dot com 2010-08-12 10:16 ---
(In reply to comment #56)
> Please stop wasting your and GCC developers time. As several people have
> explained, your code triggers undefined behavior in C/C++, so it can do
> anything at runtime. The fac
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogerio at rilhas dot com
GCC build triplet: i686-virtualboxvm-ubuntu?
GCC host triplet: i686-virtualboxvm-ubuntu?
GCC target triplet: i686-virtualboxvm-ubuntu?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #1 from rogerio at rilhas dot com 2010-08-12 14:52 ---
Created an attachment (id=21469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21469&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #2 from rogerio at rilhas dot com 2010-08-12 14:52 ---
Created an attachment (id=21470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21470&action=view)
Compilation script
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #3 from rogerio at rilhas dot com 2010-08-12 14:54 ---
Correction:
If line "char buffer[1000]; buffer[0]=0;" _is removed then_ GCC then compiles
the code as expected and "dif" will be 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #6 from rogerio at rilhas dot com 2010-08-12 15:33 ---
(In reply to comment #4)
> Pretty please, before filing further bugs take time and learn C.
> The pointer subtraction triggers undefined behavior, because one pointer
> points
> to one object and the o
--- Comment #7 from rogerio at rilhas dot com 2010-08-12 15:33 ---
(In reply to comment #5)
> ISO/IEC 9899:1999, 6.9.1 Function definitions
> 9. Each parameter has automatic storage duration. Its identifier is an lvalue,
> which is in effect declared at the head of the
--- Comment #11 from rogerio at rilhas dot com 2010-08-12 16:04 ---
(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Pretty please, before filing further bugs take time and learn C.
> > > The pointer subtraction triggers
--- Comment #15 from rogerio at rilhas dot com 2010-08-12 16:15 ---
(In reply to comment #14)
> I never claimed p1 and p2 have different types. They have the same type.
> But the standard paragraph I mentioned says:
> "When two pointers are subtracted, both shall point
--- Comment #17 from rogerio at rilhas dot com 2010-08-12 16:18 ---
(In reply to comment #12)
> Seriously, go away. I'll get far ruder if you're going to open bug reports
> worded like this:
> (In reply to comment #0)
> > Don't bother trying to understa
--- Comment #18 from rogerio at rilhas dot com 2010-08-12 16:18 ---
You know what? I did a small sample showing this bug to other people. They all
understood it, but not you. They all know what it means C99+cdecl at the same
time. You don't. I'm surprised at your lack of ca
--- Comment #22 from rogerio at rilhas dot com 2010-08-12 17:24 ---
(In reply to comment #21)
> Even without optimization (as the compilation script uses), the program
> crashes.
Right, that was the point of introducing the 1000-character buffer. With it it
crashes always.
&g
--- Comment #23 from rogerio at rilhas dot com 2010-08-12 17:25 ---
(In reply to comment #19)
> Everyone understands it, you're just wrong.
No I'm not, the problem seems to be just to complex for you because you would
have to tie up C99+cdecl to understand, but you don&#x
--- Comment #24 from rogerio at rilhas dot com 2010-08-12 17:50 ---
(In reply to comment #20)
I couldn't resist to comming back (you respond very quickly, kudos!, I'm not
used to that! :-)
> Just for fun, I compiled this test case with various levels of optimization.
&g
--- Comment #26 from rogerio at rilhas dot com 2010-08-12 18:04 ---
> You opened this bug report with insults, what sort of response do you expect?
> GCC is too crappy and amateur for your awesome code, so I suggest you stick to
> better compilers.
Will do, thanks.
... and
--- Comment #29 from rogerio at rilhas dot com 2010-08-12 18:24 ---
(In reply to comment #27)
> Oh, this fun. Enjoyable, really! ;-)
Again I couldn't resist! Everytime I'm ready to go away you say something
shocking that I simply can«t resist. Its time for me to admit I h
--- Comment #31 from rogerio at rilhas dot com 2010-08-12 18:32 ---
(In reply to comment #28)
> I built your test case with gcc and g++ without optimizations, and it worked
> fine.
Just like my script? I noticed that I'm using a not-the-newest GCC version, and
I know that
--- Comment #32 from rogerio at rilhas dot com 2010-08-12 18:38 ---
(In reply to comment #30)
> >you can't even begin to understand how to make a temporary variable an
> >l-value.
> Please look up "move constructors" and rvalue references. "move
--- Comment #34 from rogerio at rilhas dot com 2010-08-13 12:14 ---
(In reply to comment #33)
> > Not really, you could always subtract. However, far pointers gave
> > predictable addresses, just like C99 says they pointer arithmetic should.
> They didn't. I
--- Comment #38 from rogerio at rilhas dot com 2010-08-13 14:47 ---
(In reply to comment #36)
> > > If you include real segmentation
> > > like on 80286, where there's no linear relationship between effective
> > > address and segment+offset, subtracti
--- Comment #39 from rogerio at rilhas dot com 2010-08-13 14:48 ---
(In reply to comment #35)
> > char* p1=(char*)0x3000; // address not pointing to any "C-object in the C99
> > sense"
> > char* p2=(char*)0x4000; // address not pointing to any &q
--- Comment #40 from rogerio at rilhas dot com 2010-08-13 14:53 ---
(In reply to comment #37)
> (In reply to comment #36)
> > I'm not sure you realize just how true that is. But keep going, you're
> > by far one of the best trolls I've seen in GCC land
--- Comment #43 from rogerio at rilhas dot com 2010-08-13 16:28 ---
(In reply to comment #41)
> You should really adjust your glasses if you want to continue trolling with
> the high standards we're used to meanwhile:
> > > What in the words "real segmentation l
--- Comment #44 from rogerio at rilhas dot com 2010-08-13 16:30 ---
(In reply to comment #35)
> > char* p1=(char*)0x3000; // address not pointing to any "C-object in the C99
> > sense"
> > char* p2=(char*)0x4000; // address not pointing to any &q
--- Comment #46 from rogerio at rilhas dot com 2010-08-13 16:42 ---
(In reply to comment #45)
> Congratulations. Are you done now?
> What else are you hoping to achieve?
> Is this a cry for attention?
No much really. Now it is all up to the community. I just want everyone to
--- Comment #48 from rogerio at rilhas dot com 2010-08-13 21:16 ---
(In reply to comment #47)
> OK, here is the deal:
> Since you want this feature so much, I'm sure that everybody would gladly
> implement it for you, for - say - measly 5000 EUR. You can then offer
--- Comment #52 from rogerio at rilhas dot com 2010-08-14 13:17 ---
Do you really want me to go away? You are not using the right formula for that.
You know I have a problem and I can't resist. Everytime you post a message
you're just calling me back!
(In reply to c
--- Comment #55 from rogerio at rilhas dot com 2010-08-14 14:31 ---
(In reply to comment #53)
> (In reply to comment #52)
> > (In reply to comment #51)
> Look at the page history, it was removed by someone else, probably because
> your
> comment is badly written an
--- Comment #56 from rogerio at rilhas dot com 2010-08-14 14:34 ---
(In reply to comment #54)
> (In reply to comment #53)
> > GCC compiles that fine, try it.
> Sorry, I forgot my manners, what I meant is...
> Why don't you think before shooting off some crap.
> S
--- Comment #58 from rogerio at rilhas dot com 2010-08-14 16:02 ---
Why?? Why do you keep calling me back?? I was just going out and I heard the
new e-mail sound! Now I'm going to be late!!
(In reply to comment #57)
> Good way to make a convincing argument. You've tried
66 matches
Mail list logo
