segfault "caused" by unused variable in different class
-
i dont get why or how changing a variable in a different class "causes" a segfault, when the variable is not called. makes me wander if it is a symptom of a unrelated issue.
using linux, Qt Creator, c++,
void Class2::Print(std::string s) { m_file << s << '\n' << std::flush; std::cout << s << '\n' << std::flush; }
std::ofstream m_file; m_file.open("Class2OutputFile.txt");
Print() is called 22 times no issue.
connect(m_ui->pushButton_35, &QPushButton::clicked,this, &Class1::Btn_ABCParam); connect(m_ui->pushButton_32, &QPushButton::clicked,this, &Class1::Btn_XYZParam);
"causes" sigfault, but never does anything with
while(i < m_vPointA.size()) or while(i < (m_iNewPoint + 1))
debug showed what was crashing program.
if i push a button that DOES call a function that DOES deal with m_iNewPoint or m_vPointA, then no crash, all works as should.Btn_ABCParam and Btn_XYZParam, sends values to Class2, which does nothing with m_iNewPoint nor m_vPointA.
as long as
Class1::DisPlayView() Class1::PrintLocation() Class1::PrintLocationStepMtrPst()
dont get to last element of m_vPointA, then Class2::Print() has no issue with (std::string s)
i am wandering if the real issue is also causing : https://forum.qt.io/topic/142392/dont-know-what-to-call-error-bug-part-of-string-printed-to-file-and-konsole-without-calling-cout-or-std-ofstream-m_file/4
i have made a new project, and added my code to new project. same error
-
Please provide a minimal, compilable example to reproduce your issue - it's impossible to see something from your code fragments...
Apart from this - unitinitalized variables may contain anything so everything can happen when they are accessed. -
Please provide a minimal, compilable example to reproduce your issue - it's impossible to see something from your code fragments...
Apart from this - unitinitalized variables may contain anything so everything can happen when they are accessed.@Christian-Ehrlicher said in segfault "caused" by unused variable in different class:
Please provide a minimal, compilable example to reproduce your issue - it's impossible to see something from your code fragments...
Apart from this - unitinitalized variables may contain anything so everything can happen when they are accessed.the variable ARE NOT accessed, uninitialized or initialized
to repeat what i already said, variable that is "causing" sigfault, has absolutely nothing to do with the function that sigfault occurs in.at first i thought m_iNewPoint was causing the crash, because if i changed m_iNewPoint [which is at minimum initializing] to one less than size of m_vPointA, then there was no crash.
Class2 has only one function, that tells Class1 to do anything with m_vPointA nor m_iNewPoint. Class2 does not have any functions that call m_vPointA nor m_iNewPoint. Only Class1 can touch m_vPointA or m_iNewPoint.
The minimum code, would be the whole project.
anything done in Class1 that uses m_vPointA or m_iNewPoint, doe not "cause" a sigfault.
It is like putting fuel in a car in mexico, and a house in canada explodes.
-
The moral of the story... don't refuel in Mexico!
All we can say is that:
- if executing the two connect() calls causes a segfault then m_ui, m_ui->pushButton_35, and m_ui->pushButton_32 are all candidates for being uninitialised or undefined.
- if executing whatever is in Class1::Btn_ABCParam() or Class1::Btn_XYZParam() causes the segfault then the problem is there.
Any other relationship between these two connect() statements and anything else in your post is unclear.
as long as
Class1::DisPlayView()
Class1::PrintLocation()
Class1::PrintLocationStepMtrPst()dont get to last element of m_vPointA, then Class2::Print() has no issue with (std::string s)
This strongly suggests one, some, or all, of these methods runs off the end of a list, attempt out of bounds access of m_vPointA (whatever that object is), or that last element in m_vPointA is invalid or undefined.
Run your program in the debugger and, when it crashes, copy and paste:
- the ASSERT or other output from the console
- the entire stack back trace
- the lines of code around the first line or your code mentioned in the back trace
-
The moral of the story... don't refuel in Mexico!
All we can say is that:
- if executing the two connect() calls causes a segfault then m_ui, m_ui->pushButton_35, and m_ui->pushButton_32 are all candidates for being uninitialised or undefined.
- if executing whatever is in Class1::Btn_ABCParam() or Class1::Btn_XYZParam() causes the segfault then the problem is there.
Any other relationship between these two connect() statements and anything else in your post is unclear.
as long as
Class1::DisPlayView()
Class1::PrintLocation()
Class1::PrintLocationStepMtrPst()dont get to last element of m_vPointA, then Class2::Print() has no issue with (std::string s)
This strongly suggests one, some, or all, of these methods runs off the end of a list, attempt out of bounds access of m_vPointA (whatever that object is), or that last element in m_vPointA is invalid or undefined.
Run your program in the debugger and, when it crashes, copy and paste:
- the ASSERT or other output from the console
- the entire stack back trace
- the lines of code around the first line or your code mentioned in the back trace
@ChrisW67 said in segfault "caused" by unused variable in different class:
The moral of the story... don't refuel in Mexico!
All we can say is that:
- if executing the two connect() calls causes a segfault then m_ui, m_ui->pushButton_35, and m_ui->pushButton_32 are all candidates for being uninitialised or undefined.
- if executing whatever is in Class1::Btn_ABCParam() or Class1::Btn_XYZParam() causes the segfault then the problem is there.
this makes sense, but does not explain allowing unrelated code being able to see last element of m_vPointA, that is not called.
Any other relationship between these two connect() statements and anything else in your post is unclear.
as long as
Class1::DisPlayView()
Class1::PrintLocation()
Class1::PrintLocationStepMtrPst()dont get to last element of m_vPointA, then Class2::Print() has no issue with (std::string s)
there is not relations, other then being in Class1 with the two buttons connects. that is why i did not look at those the two functions that are connected to the two buttons
This strongly suggests one, some, or all, of these methods runs off the end of a list, attempt out of bounds access of m_vPointA (whatever that object is), or that last element in m_vPointA is invalid or undefined.
"strongly suggests" but as i said several times, m_iNewPoint is initialized, and m_vPointA is accessed one less than m_vPointA.size(), by different methods, does not "cause" sigfault, but m_iNewPoint == m_vPointA.size() does "cause" sigfault.
Run your program in the debugger and, when it crashes, copy and paste:
- the ASSERT or other output from the console
- the entire stack back trace
- the lines of code around the first line or your code mentioned in the back trace
ok
-
The moral of the story... don't refuel in Mexico!
All we can say is that:
- if executing the two connect() calls causes a segfault then m_ui, m_ui->pushButton_35, and m_ui->pushButton_32 are all candidates for being uninitialised or undefined.
- if executing whatever is in Class1::Btn_ABCParam() or Class1::Btn_XYZParam() causes the segfault then the problem is there.
Any other relationship between these two connect() statements and anything else in your post is unclear.
as long as
Class1::DisPlayView()
Class1::PrintLocation()
Class1::PrintLocationStepMtrPst()dont get to last element of m_vPointA, then Class2::Print() has no issue with (std::string s)
This strongly suggests one, some, or all, of these methods runs off the end of a list, attempt out of bounds access of m_vPointA (whatever that object is), or that last element in m_vPointA is invalid or undefined.
Run your program in the debugger and, when it crashes, copy and paste:
- the ASSERT or other output from the console
- the entire stack back trace
- the lines of code around the first line or your code mentioned in the back trace
@ChrisW67 said in segfault "caused" by unused variable in different class:
Run your program in the debugger and, when it crashes, copy and paste:
- the ASSERT or other output from the console
nothing
- the entire stack back trace
i would like to know where to find stack. dont see a button/tab for stack
- the lines of code around the first line or your code mentioned in the back trace
-
@ChrisW67 said in segfault "caused" by unused variable in different class:
The moral of the story... don't refuel in Mexico!
All we can say is that:
- if executing the two connect() calls causes a segfault then m_ui, m_ui->pushButton_35, and m_ui->pushButton_32 are all candidates for being uninitialised or undefined.
- if executing whatever is in Class1::Btn_ABCParam() or Class1::Btn_XYZParam() causes the segfault then the problem is there.
this makes sense, but does not explain allowing unrelated code being able to see last element of m_vPointA, that is not called.
Any other relationship between these two connect() statements and anything else in your post is unclear.
as long as
Class1::DisPlayView()
Class1::PrintLocation()
Class1::PrintLocationStepMtrPst()dont get to last element of m_vPointA, then Class2::Print() has no issue with (std::string s)
there is not relations, other then being in Class1 with the two buttons connects. that is why i did not look at those the two functions that are connected to the two buttons
This strongly suggests one, some, or all, of these methods runs off the end of a list, attempt out of bounds access of m_vPointA (whatever that object is), or that last element in m_vPointA is invalid or undefined.
"strongly suggests" but as i said several times, m_iNewPoint is initialized, and m_vPointA is accessed one less than m_vPointA.size(), by different methods, does not "cause" sigfault, but m_iNewPoint == m_vPointA.size() does "cause" sigfault.
Run your program in the debugger and, when it crashes, copy and paste:
- the ASSERT or other output from the console
- the entire stack back trace
- the lines of code around the first line or your code mentioned in the back trace
ok
@ChrisW67 said in segfault "caused" by unused variable in different class:
i found this. no clue what it is
5022 [1] { 0x55842709e972 f3 0f 1e fa endbr64 0x55842709e976 <+ 4> 55 push %rbp 0x55842709e977 <+ 5> 48 89 e5 mov %rsp,%rbp 0x55842709e97a <+ 8> 48 83 ec 10 sub $0x10,%rsp 0x55842709e97e <+ 12> 48 89 7d f8 mov %rdi,-0x8(%rbp) 0x55842709e982 <+ 16> 48 89 75 f0 mov %rsi,-0x10(%rbp) 5023 [1] m_file << s << '\n' << std::flush; 0x55842709e986 <+ 20> 48 8b 45 f8 mov -0x8(%rbp),%rax 0x55842709e98a <+ 24> 48 8d 50 18 lea 0x18(%rax),%rdx 0x55842709e98e <+ 28> 48 8b 45 f0 mov -0x10(%rbp),%rax 0x55842709e992 <+ 32> 48 89 c6 mov %rax,%rsi 0x55842709e995 <+ 35> 48 89 d7 mov %rdx,%rdi 0x55842709e998 <+ 38> e8 f3 3b fd ff callq 0x558427072590 <_ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKNSt7__cxx1112basic_stringIS4_S5_T1_EE@plt> 0x55842709e99d <+ 43> be 0a 00 00 00 mov $0xa,%esi 0x55842709e9a2 <+ 48> 48 89 c7 mov %rax,%rdi 0x55842709e9a5 <+ 51> e8 96 36 fd ff callq 0x558427072040 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c@plt> 0x55842709e9aa <+ 56> 48 89 c2 mov %rax,%rdx 0x55842709e9ad <+ 59> 48 8b 05 0c 46 07 00 mov 0x7460c(%rip),%rax # 0x558427112fc0 0x55842709e9b4 <+ 66> 48 89 c6 mov %rax,%rsi 0x55842709e9b7 <+ 69> 48 89 d7 mov %rdx,%rdi 0x55842709e9ba <+ 72> e8 e1 3e fd ff callq 0x5584270728a0 <_ZNSolsEPFRSoS_E@plt> 5024 [1] std::cout << s << '\n' << std::flush; 0x55842709e9bf <+ 77> 48 8b 45 f0 mov -0x10(%rbp),%rax 0x55842709e9c3 <+ 81> 48 89 c6 mov %rax,%rsi 0x55842709e9c6 <+ 84> 48 8b 05 9b 45 07 00 mov 0x7459b(%rip),%rax # 0x558427112f68 0x55842709e9cd <+ 91> 48 89 c7 mov %rax,%rdi 0x55842709e9d0 <+ 94> e8 bb 3b fd ff callq 0x558427072590 <_ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKNSt7__cxx1112basic_stringIS4_S5_T1_EE@plt> 0x55842709e9d5 <+ 99> be 0a 00 00 00 mov $0xa,%esi 0x55842709e9da <+ 104> 48 89 c7 mov %rax,%rdi 0x55842709e9dd <+ 107> e8 5e 36 fd ff callq 0x558427072040 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c@plt> 0x55842709e9e2 <+ 112> 48 89 c2 mov %rax,%rdx 0x55842709e9e5 <+ 115> 48 8b 05 d4 45 07 00 mov 0x745d4(%rip),%rax # 0x558427112fc0 0x55842709e9ec <+ 122> 48 89 c6 mov %rax,%rsi 0x55842709e9ef <+ 125> 48 89 d7 mov %rdx,%rdi 0x55842709e9f2 <+ 128> e8 a9 3e fd ff callq 0x5584270728a0 <_ZNSolsEPFRSoS_E@plt> 5025 [1] } 0x55842709e9f7 <+ 133> 90 nop 0x55842709e9f8 <+ 134> c9 leaveq 0x55842709e9f9 <+ 135> c3 retq
-
Ensure you build a debug version of your project:
then run the program in the debugger:
generate the crash:
then look at the debugger panes at the bottom of your screen. The left panel is the back trace (yours will be longer). Right-click to copy the text:
Select the top-most line in the back trace that is in your code. There is a panel that shows the variables in scope at the time of the call selected.
-
Ensure you build a debug version of your project:
then run the program in the debugger:
generate the crash:
then look at the debugger panes at the bottom of your screen. The left panel is the back trace (yours will be longer). Right-click to copy the text:
Select the top-most line in the back trace that is in your code. There is a panel that shows the variables in scope at the time of the call selected.
@ChrisW67 the panel that shows variables, is open by default, and has no title. it says
s <not accessible> std::string
which is weird, every call to Print(), has a stringwhat was copied to clip board:
1 std::ostream::sentry::sentry(std::ostream&) 0x7f5783825f27
2 std::basic_ostream<char, std::char_traits<char>>& std::__ostream_insert<char, std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, const char *, long) 0x7f57838266cc
3 Class2::Print CControls.cpp 5023 0x55db831e499d
4 Class2::CheckABCParam CControls.cpp 39 0x55db831b9036
5 Class3::CheckABCParam Class3.cpp 90 0x55db8322a1ce
6 Class1::Btn_ABCParam CGUI.cpp 856 0x55db831f9599
7 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (Class1:: *)()>::call(void (Class1:: *)(), Class1 *, void * *) qobjectdefs_impl.h 152 0x55db83228a69
8 QtPrivate::FunctionPointer<void (Class1:: *)()>::call<QtPrivate::List<>, void>(void (Class1:: *)(), Class1 *, void * *) qobjectdefs_impl.h 185 0x55db8322879a
9 QtPrivate::QSlotObject<void (Class1:: *)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void * *, bool *) qobjectdefs_impl.h 414 0x55db832281c8
10 QMetaObject::activate(QObject *, int, int, void * *) 0x7f5783b87328
11 QAbstractButton::clicked(bool) 0x7f5784683806
12 ?? 0x7f5784683a2e
13 ?? 0x7f5784684e73
14 QAbstractButton::mouseReleaseEvent(QMouseEvent *) 0x7f5784685035
15 QWidget::event(QEvent *) 0x7f57845d12b6
16 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7f578458ea66
17 QApplication::notify(QObject *, QEvent *) 0x7f5784598343
18 QCoreApplication::notifyInternal2(QObject *, QEvent *) 0x7f5783b5b80a
19 QApplicationPrivate::sendMouseEvent(QWidget *, QMouseEvent *, QWidget *, QWidget *, QWidget * *, QPointer<QWidget>&, bool, bool) 0x7f5784597457
20 ?? 0x7f57845ed35d
... <More>it does not explain how changing a variable for a vector, that is not used, is causing a string to be empty, that has nothing to do with the changed variable, nor a vector
-
@ChrisW67 the panel that shows variables, is open by default, and has no title. it says
s <not accessible> std::string
which is weird, every call to Print(), has a stringwhat was copied to clip board:
1 std::ostream::sentry::sentry(std::ostream&) 0x7f5783825f27
2 std::basic_ostream<char, std::char_traits<char>>& std::__ostream_insert<char, std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, const char *, long) 0x7f57838266cc
3 Class2::Print CControls.cpp 5023 0x55db831e499d
4 Class2::CheckABCParam CControls.cpp 39 0x55db831b9036
5 Class3::CheckABCParam Class3.cpp 90 0x55db8322a1ce
6 Class1::Btn_ABCParam CGUI.cpp 856 0x55db831f9599
7 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (Class1:: *)()>::call(void (Class1:: *)(), Class1 *, void * *) qobjectdefs_impl.h 152 0x55db83228a69
8 QtPrivate::FunctionPointer<void (Class1:: *)()>::call<QtPrivate::List<>, void>(void (Class1:: *)(), Class1 *, void * *) qobjectdefs_impl.h 185 0x55db8322879a
9 QtPrivate::QSlotObject<void (Class1:: *)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void * *, bool *) qobjectdefs_impl.h 414 0x55db832281c8
10 QMetaObject::activate(QObject *, int, int, void * *) 0x7f5783b87328
11 QAbstractButton::clicked(bool) 0x7f5784683806
12 ?? 0x7f5784683a2e
13 ?? 0x7f5784684e73
14 QAbstractButton::mouseReleaseEvent(QMouseEvent *) 0x7f5784685035
15 QWidget::event(QEvent *) 0x7f57845d12b6
16 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7f578458ea66
17 QApplication::notify(QObject *, QEvent *) 0x7f5784598343
18 QCoreApplication::notifyInternal2(QObject *, QEvent *) 0x7f5783b5b80a
19 QApplicationPrivate::sendMouseEvent(QWidget *, QMouseEvent *, QWidget *, QWidget *, QWidget * *, QPointer<QWidget>&, bool, bool) 0x7f5784597457
20 ?? 0x7f57845ed35d
... <More>it does not explain how changing a variable for a vector, that is not used, is causing a string to be empty, that has nothing to do with the changed variable, nor a vector
????????
i replacewhile(i < (m_vPointA.size() - 0))
with
while(i < (m_vPointA.size() - 1))
so i can move on. getting the last value in vectors are not a big deal, what is causing the unrelated segfault, is.
got another unrelated segfault at same point by removing
m_sState = "stop"
, but this time in Class2, which also has absolutely nothing to do with
Class2::CheckABCParam()
, sending a string to
Class2::Print()
???????????????????????????????????????????????????????????
remove all 6m_sState = "stop"
at same time, it segfaults in unrelated code
remove one at a time, run debug, repeat untill all 6 are removed, and it does not???????? -
I detect a strong odor of pointer problems.
-
I detect a strong odor of pointer problems.
@Kent-Dorfman said in segfault "caused" by unused variable in different class:
I detect a strong odor of pointer problems.
i am getting random segfault at
Class2::Print()
, but most dont occur everytime. the one involving
(m_vPointA.size()
is the only one that occurred every time for two days
lets go with pointer error. how to track it down?