public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* segfault when functions are defined in headers or inlined
@ 2015-07-10  9:50 achkan
  2015-07-10 10:33 ` Jonathan Wakely
  0 siblings, 1 reply; 8+ messages in thread
From: achkan @ 2015-07-10  9:50 UTC (permalink / raw)
  To: gcc-help

Hi,

Being from the computer vision community, I'm not sure who to turn to when
it comes to compiler problems, so I apologize in advance in case this is not
the most appropriate place to post this question.

The library that I'm trying to compile segfaults whenever an inlined member
function returns. Inspecting the code with gdb shows that the following
happens for all inline member functions (I'm really sorry, the code is
proprietary but I will post code as close as possible to the original one) : 

//in the header of an given class
ret & some_class::get_some_member()
{
   return this->_some_member;* //the address of some member is the same it
was when the this instance was created
}

//where the call is made
var=some_class_instance.get_some_member();//the address of the variable
changes. The function actually returns a new
                                                                    
//instance of _some_member, using its default constructor
                                                                     //which
later results in segfaults

The only solution that I have found is to remove the function definition
from the headers to the .cpp files. That way, the adress that function
returns is correct, and execution continues until the next inlined function
and the next segfault. Given that the library is quite large, removing
definition from headers is not an option. Furthermore, it seems to me that
g++ ignores the -fno-inline flag even though I have removed every
optimization flag. Is this a known issue? 

I'm working on Ubuntu 14.04 64bit, with g++ version g++ (Ubuntu
4.8.4-2ubuntu1~14.04) 4.8.4.

 Any help will greatly be appreciated.
 
Achkan SALEHI
achkan.salehi@cea.fr
ashsalehi4133@gmail.com



--
View this message in context: http://gcc.1065356.n5.nabble.com/segfault-when-functions-are-defined-in-headers-or-inlined-tp1167297.html
Sent from the gcc - Help mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: segfault when functions are defined in headers or inlined
  2015-07-10  9:50 segfault when functions are defined in headers or inlined achkan
@ 2015-07-10 10:33 ` Jonathan Wakely
  2015-07-10 11:04   ` achkan
  0 siblings, 1 reply; 8+ messages in thread
From: Jonathan Wakely @ 2015-07-10 10:33 UTC (permalink / raw)
  To: achkan; +Cc: gcc-help

On 10 July 2015 at 10:50, achkan wrote:
> The library that I'm trying to compile segfaults whenever an inlined member
> function returns. Inspecting the code with gdb shows that the following
> happens for all inline member functions (I'm really sorry, the code is
> proprietary but I will post code as close as possible to the original one) :

The code you've shown is useless, we don't know how ret or some_class
is defined, or how you've declared the instance of some_class.

If your problem happens with *all* inline functions then you should be
able to write a simple, self-contained, *complete* program that shows
the problem. Without working code that demonstrates the problem my
best guess is you're writing buggy code, because noone else sees the
behaviour you are describing (and thousands and thousands of people
use G++ on Ubuntu without this problem).

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: segfault when functions are defined in headers or inlined
  2015-07-10 10:33 ` Jonathan Wakely
@ 2015-07-10 11:04   ` achkan
  2015-07-10 11:10     ` Jonathan Wakely
  0 siblings, 1 reply; 8+ messages in thread
From: achkan @ 2015-07-10 11:04 UTC (permalink / raw)
  To: gcc-help

Thanks a lot for you answer. Yes, this happens with every inline function. If
I could write a simple, self-contained complete program that shows the
problem, I would gladly do it (I think this would take me more than a
year...). Anyhow, I am not asking you to debug our code, but whether or not
anyone has ever encountered this problem: "code that segfaults for every
inline 
function, and no segfault when the definition is put in the .cpp files
instead of the headers." .  If, no, then well... too bad for me :)  thanks
again.



--
View this message in context: http://gcc.1065356.n5.nabble.com/segfault-when-functions-are-defined-in-headers-or-inlined-tp1167297p1167315.html
Sent from the gcc - Help mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: segfault when functions are defined in headers or inlined
  2015-07-10 11:04   ` achkan
@ 2015-07-10 11:10     ` Jonathan Wakely
  2015-07-10 11:21       ` achkan
  0 siblings, 1 reply; 8+ messages in thread
From: Jonathan Wakely @ 2015-07-10 11:10 UTC (permalink / raw)
  To: achkan; +Cc: gcc-help

On 10 July 2015 at 12:04, achkan wrote:
> Thanks a lot for you answer. Yes, this happens with every inline function. If
> I could write a simple, self-contained complete program that shows the
> problem, I would gladly do it (I think this would take me more than a
> year...).

That's ridiculous. If it happens with *every* function then you could
write a single file with one inline function and call it from main(),
if that fails you've reproduced the problem (in a lot less than a
year!) and if it doesn't fail then it proves it doesn't happen for
*every* function and there must be something particular to your
library. Maybe http://stackoverflow.com/help/mcve will help.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: segfault when functions are defined in headers or inlined
  2015-07-10 11:10     ` Jonathan Wakely
@ 2015-07-10 11:21       ` achkan
  2015-07-10 14:32         ` Ángel González
  0 siblings, 1 reply; 8+ messages in thread
From: achkan @ 2015-07-10 11:21 UTC (permalink / raw)
  To: gcc-help

When is said every function I meant every function from the library (which
uses a lot of stuff... Torch7, wxWidget, opengl, eigen, opencv...). I
wouldn't know how to reproduce its behavior. But I'm sure that this problem
happens only when I include the wxWidget headers (the console versions do
not segfault.). Is it possible for a library to cause the problem I'm
talking about? I mean how can
leaky code, or any memory problems be avoided just by moving the definition
to the cpp?? But yeah you're right. I'll see if I can do that.

On Fri, Jul 10, 2015 at 1:10 PM, Jonathan Wakely-4 [via gcc] <
ml-node+s1065356n1167319h13@n5.nabble.com> wrote:

> On 10 July 2015 at 12:04, achkan wrote:
> > Thanks a lot for you answer. Yes, this happens with every inline
> function. If
> > I could write a simple, self-contained complete program that shows the
> > problem, I would gladly do it (I think this would take me more than a
> > year...).
>
> That's ridiculous. If it happens with *every* function then you could
> write a single file with one inline function and call it from main(),
> if that fails you've reproduced the problem (in a lot less than a
> year!) and if it doesn't fail then it proves it doesn't happen for
> *every* function and there must be something particular to your
> library. Maybe http://stackoverflow.com/help/mcve will help.
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://gcc.1065356.n5.nabble.com/segfault-when-functions-are-defined-in-headers-or-inlined-tp1167297p1167319.html
>  To unsubscribe from segfault when functions are defined in headers or
> inlined, click here
> <http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1167297&code=YXNoc2FsZWhpNDEzM0BnbWFpbC5jb218MTE2NzI5N3wtMTcwMzA2MTky>
> .
> NAML
> <http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://gcc.1065356.n5.nabble.com/segfault-when-functions-are-defined-in-headers-or-inlined-tp1167297p1167320.html
Sent from the gcc - Help mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: segfault when functions are defined in headers or inlined
  2015-07-10 11:21       ` achkan
@ 2015-07-10 14:32         ` Ángel González
  2015-07-10 15:32           ` achkan
  0 siblings, 1 reply; 8+ messages in thread
From: Ángel González @ 2015-07-10 14:32 UTC (permalink / raw)
  To: gcc-help

On 10/07/15 13:21, achkan wrote:
> When is said every function I meant every function from the library (which
> uses a lot of stuff... Torch7, wxWidget, opengl, eigen, opencv...). I
> wouldn't know how to reproduce its behavior. But I'm sure that this problem
> happens only when I include the wxWidget headers (the console versions do
> not segfault.). Is it possible for a library to cause the problem I'm
> talking about? I mean how can
> leaky code, or any memory problems be avoided just by moving the definition
> to the cpp?? But yeah you're right. I'll see if I can do that.

Are you using an already-built library file?
A mismatch between the library object and the headers you use could cause
what you are seeing. I would try recompiling the library.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: segfault when functions are defined in headers or inlined
  2015-07-10 14:32         ` Ángel González
@ 2015-07-10 15:32           ` achkan
  0 siblings, 0 replies; 8+ messages in thread
From: achkan @ 2015-07-10 15:32 UTC (permalink / raw)
  To: gcc-help

Thank you both for your time. Actually yes, I was using the wxWidget
precompiled libraries from ubuntu repositories, and it appears that some
macro from that library is responsible.  I will just drop that library and
stick to a simple glfw window instead. wxWidgets is a pain anyway.
@johnsfine: yes I meant val&. Still have no idea how wxwidget affects how
functions are inlined though...

On Fri, Jul 10, 2015 at 4:32 PM, Ángel González [via gcc] <
ml-node+s1065356n1167405h79@n5.nabble.com> wrote:

> On 10/07/15 13:21, achkan wrote:
> > When is said every function I meant every function from the library
> (which
> > uses a lot of stuff... Torch7, wxWidget, opengl, eigen, opencv...). I
> > wouldn't know how to reproduce its behavior. But I'm sure that this
> problem
> > happens only when I include the wxWidget headers (the console versions
> do
> > not segfault.). Is it possible for a library to cause the problem I'm
> > talking about? I mean how can
> > leaky code, or any memory problems be avoided just by moving the
> definition
> > to the cpp?? But yeah you're right. I'll see if I can do that.
>
> Are you using an already-built library file?
> A mismatch between the library object and the headers you use could cause
> what you are seeing. I would try recompiling the library.
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://gcc.1065356.n5.nabble.com/segfault-when-functions-are-defined-in-headers-or-inlined-tp1167297p1167405.html
>  To unsubscribe from segfault when functions are defined in headers or
> inlined, click here
> <http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1167297&code=YXNoc2FsZWhpNDEzM0BnbWFpbC5jb218MTE2NzI5N3wtMTcwMzA2MTky>
> .
> NAML
> <http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://gcc.1065356.n5.nabble.com/segfault-when-functions-are-defined-in-headers-or-inlined-tp1167297p1167427.html
Sent from the gcc - Help mailing list archive at Nabble.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: segfault when functions are defined in headers or inlined
@ 2015-07-10 14:28 johnsfine
  0 siblings, 0 replies; 8+ messages in thread
From: johnsfine @ 2015-07-10 14:28 UTC (permalink / raw)
  To: ashsalehi4133, gcc-help

 Even if the function returns a ref, the assignment (as you showed it) would not capture the ref.  It would assign the value.

I think you probably wanted
ret& var=some_class_instance.get_some_member();

I think the problem with inlining, that you think you are seeing, is just what I always call "stirring the pot".  When you have a serious bug, the symptoms may be hidden.  When you make an irrelevant change the symptoms might appear or disappear creating the illusion that the irrelevant change was relevant.  You haven't added or removed the bug, just stirred things to change the appearance of the bug.

I don't think there is a real chance of a gcc bug in all this, so this is likely the wrong forum for a serious discussion of the problem.  In the right forum, you would need to post more detail of the relevant declarations to get better help.


 

On 07/10/15, achkan wrote:


ret & some_class::get_some_member()
...
var=some_class_instance.get_some_member();//the address of the variable

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-07-10 15:32 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-10  9:50 segfault when functions are defined in headers or inlined achkan
2015-07-10 10:33 ` Jonathan Wakely
2015-07-10 11:04   ` achkan
2015-07-10 11:10     ` Jonathan Wakely
2015-07-10 11:21       ` achkan
2015-07-10 14:32         ` Ángel González
2015-07-10 15:32           ` achkan
2015-07-10 14:28 johnsfine

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).