Re: stack trace for bug #755
On 11 November 2014 20:55, Dirk Hohndel wrote: > On Tue, Nov 11, 2014 at 06:42:34PM +0200, Lubomir I. Ivanov wrote: >> On 11 November 2014 17:23, Lubomir I. Ivanov wrote: >> > >> > but i think i found another one: >> >> - start new divelog >> >> - import dives/test0.xml-test38.xml >> > - select first dive in the trip >> > - select second dive in the trip (dive #35?) >> > >> > it enters an infinite loop allocating 3MB per second while frozen. >> > >> >> i'm a bit confused about this one... >> >> created ticked: >> http://trac.subsurface-divelog.org/ticket/759#ticket >> >> ticket text: >> -- >> >> Qt 5.3.0, win7 64bit, SHA1: d06cc2c68e10bb3 >> >> start subsurface >> load ./dives/test35.xml > > Above you say open all of them, here you say just load that one. > >> the dctype='CCR' attribute in test35.xml is causing an infinite loop. >> if i put this line: > > This doesn't happen for me - I can open test35.xml just fine (latest > master, Linux). > i think it's due to the fact i have the partial pressure graphs enabled, but i haven't tested this. anyway, here is a patch for the bug but i'm CCing the author of the code as i really don't have much of an idea what a diluent cyclinder actually is, apart from the fact that i just saw a picture of it via google. if there is a better fix, please ignore the patch. - In a test case loading dives/test35.xml results in a infinite(-like) loop (Note: possibly requires the partial pressure plots enabled). calculate_gas_information_new() has an 'if' branch to update the cylinderindex to a dive's diluent_cylinder_index, but it does not consider that said index can be set previously to -1. This results in a random neighbour memory assigned as &dive->cylinder[-1].gasmix and passed to fill_pressures(..). Following the calculations in the function the He gas, can receive a bad value (e.g. for the test case in the E+6 ranges). Said value is then used in DivePlotDataModel()::pheMax() (defined by MAX_PPGAS_FUNC()) resulting in one of the loops (the 3rd one) in DiveCartesianAxis::updateTicks() to loop indefinitely. - difficult to debug, mainly due to Qt's "signal / slot / emit" mechanics and the "model / view" network of "stuff" - not much fun. also the backtrace from GDB was somewhere in kernel32.dll, which is not useful at all, so i had to do the good-old: add some breakpoints -> step / next (100 times) -> -> quit -> add more printf()'s -> recompile -> check values -> repeat... (etc) lubomir -- 0001-profile.c-fix-a-bug-in-calculate_gas_information_new.patch Description: Binary data ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On Tue, Nov 11, 2014 at 09:46:19PM +0200, Lubomir I. Ivanov wrote:
> >>
> >> And the line calling strdup (in case my sources are slightly off sync):
> >>
> >> if (!same_string(displayedTrip.location, currentTrip->location)) {
> >> currentTrip->location = strdup(displayedTrip.location);
> >> mark_divelist_changed(true);
> >> }
> >
> > That "strdup()" really should be "copy_string()".
Yes, whenever there's a possibility that the argument is NULL we really
should use copy_string(). That's why we have it.
> here is a patch for that.
> no crash occurs on win32, yet i can see NULL values reaching the
> same_string() checks.
Thanks. I wonder if the infinite loop you are observing is also dependent
on differen libc implementations... I don't see anything obvious that
stands out, though...
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On 11 November 2014 21:20, Linus Torvalds wrote:
> On Tue, Nov 11, 2014 at 5:45 AM, Miika Turkia wrote:
>>
>> And the line calling strdup (in case my sources are slightly off sync):
>>
>> if (!same_string(displayedTrip.location, currentTrip->location)) {
>> currentTrip->location = strdup(displayedTrip.location);
>> mark_divelist_changed(true);
>> }
>
> That "strdup()" really should be "copy_string()".
>
> The whole "same_string()" thing counts NULL as en empty string, so it
> allows NULL. And that's *exactly* why we have "copy_string()" too,
> allowing NULL (which will be copied as NULL).
>
here is a patch for that.
no crash occurs on win32, yet i can see NULL values reaching the
same_string() checks.
lubomir
--
0001-maintab.cpp-use-copy_string-instead-of-strdup.patch
Description: Binary data
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On 11 November 2014 20:55, Dirk Hohndel wrote: > On Tue, Nov 11, 2014 at 06:42:34PM +0200, Lubomir I. Ivanov wrote: >> On 11 November 2014 17:23, Lubomir I. Ivanov wrote: >> > >> > but i think i found another one: >> >> - start new divelog >> >> - import dives/test0.xml-test38.xml >> > - select first dive in the trip >> > - select second dive in the trip (dive #35?) >> > >> > it enters an infinite loop allocating 3MB per second while frozen. >> > >> >> i'm a bit confused about this one... >> >> created ticked: >> http://trac.subsurface-divelog.org/ticket/759#ticket >> >> ticket text: >> -- >> >> Qt 5.3.0, win7 64bit, SHA1: d06cc2c68e10bb3 >> >> start subsurface >> load ./dives/test35.xml > > Above you say open all of them, here you say just load that one. > happens with just 35, for the infinite loop. miika's bug i cannot reproduce, which he listed with all dives as a step. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On Tue, Nov 11, 2014 at 5:45 AM, Miika Turkia wrote:
>
> And the line calling strdup (in case my sources are slightly off sync):
>
> if (!same_string(displayedTrip.location, currentTrip->location)) {
> currentTrip->location = strdup(displayedTrip.location);
> mark_divelist_changed(true);
> }
That "strdup()" really should be "copy_string()".
The whole "same_string()" thing counts NULL as en empty string, so it
allows NULL. And that's *exactly* why we have "copy_string()" too,
allowing NULL (which will be copied as NULL).
Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On Tue, Nov 11, 2014 at 06:42:34PM +0200, Lubomir I. Ivanov wrote: > On 11 November 2014 17:23, Lubomir I. Ivanov wrote: > > > > but i think i found another one: > >> - start new divelog > >> - import dives/test0.xml-test38.xml > > - select first dive in the trip > > - select second dive in the trip (dive #35?) > > > > it enters an infinite loop allocating 3MB per second while frozen. > > > > i'm a bit confused about this one... > > created ticked: > http://trac.subsurface-divelog.org/ticket/759#ticket > > ticket text: > -- > > Qt 5.3.0, win7 64bit, SHA1: d06cc2c68e10bb3 > > start subsurface > load ./dives/test35.xml Above you say open all of them, here you say just load that one. > the dctype='CCR' attribute in test35.xml is causing an infinite loop. > if i put this line: This doesn't happen for me - I can open test35.xml just fine (latest master, Linux). /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On 11 November 2014 17:23, Lubomir I. Ivanov wrote:
>
> but i think i found another one:
>> - start new divelog
>> - import dives/test0.xml-test38.xml
> - select first dive in the trip
> - select second dive in the trip (dive #35?)
>
> it enters an infinite loop allocating 3MB per second while frozen.
>
i'm a bit confused about this one...
created ticked:
http://trac.subsurface-divelog.org/ticket/759#ticket
ticket text:
--
Qt 5.3.0, win7 64bit, SHA1: d06cc2c68e10bb3
start subsurface
load ./dives/test35.xml
the dctype='CCR' attribute in test35.xml is causing an infinite loop.
if i put this line:
puts("<---reached");
after:
dataModel->emitDataChanged();
in ProfileWidget2::plotDive()
it's never reached. wasn't able to debug it further...
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: stack trace for bug #755
On 11 November 2014 15:45, Miika Turkia wrote:
> #0 strlen () at ../sysdeps/x86_64/strlen.S:106
> #1 0x720b523e in __GI___strdup (s=0x0) at strdup.c:41
> #2 0x004982e8 in MainTab::acceptChanges (this=this@entry=0x936320)
> at ../qt-ui/maintab.cpp:698
to me it looks like the stacktrace suggests displayedTrip.location is
NULL when it reaches strdup().
if (!same_string(displayedTrip.notes, currentTrip->notes)) {
currentTrip->notes = strdup(displayedTrip.notes);
mark_divelist_changed(true);
}
if (!same_string(displayedTrip.location, currentTrip->location)) {
currentTrip->location = strdup(displayedTrip.location);
mark_divelist_changed(true);
}
^ i don't think this code is reliable because same_string() -> false
would still pass even if one of the strings is NULL, but not sure if
that should ever happen.
but if does, entering the branches:
currentTrip->notes = strdup(displayedTrip.notes);
..
currentTrip->location = strdup(displayedTrip.location);
will surely SIGSEGV for most c libs.
> I do not have my trac password with me so I cannot comment on the actual bug
> report. But here is a stack trace from current master version of Subsurface
> (Ubuntu 14.10 as in the bug report).
>
>
> Reproduction steps:
> - start new divelog
> - import dives/test0.xml-test38.xml
> - select the trip on top of the divelist
> - edit notes
> - save
(current master, win32)
strangely the above doesn't produce a crash for me - editing both
location and notes, then saving:
but i think i found another one:
> - start new divelog
> - import dives/test0.xml-test38.xml
- select first dive in the trip
- select second dive in the trip (dive #35?)
it enters an infinite loop allocating 3MB per second while frozen.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
stack trace for bug #755
I do not have my trac password with me so I cannot comment on the actual
bug report. But here is a stack trace from current master version of
Subsurface (Ubuntu 14.10 as in the bug report).
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x720b523e in __GI___strdup (s=0x0) at strdup.c:41
#2 0x004982e8 in MainTab::acceptChanges (this=this@entry=0x936320)
at ../qt-ui/maintab.cpp:698
#3 0x00542850 in MainTab::qt_static_metacall (_o=0x936320,
_id=, _a=0x7fffd130, _c=) at
.moc/moc_maintab.cpp:122
#4 0x72db3a7a in QMetaObject::activate(QObject*, QMetaObject
const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5 0x73613bf2 in QAction::triggered(bool) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6 0x736155c3 in QAction::activate(QAction::ActionEvent) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7 0x739d4d9f in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8 0x739d4ed4 in QAbstractButton::mouseReleaseEvent(QMouseEvent*)
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#9 0x73a8c32a in QToolButton::mouseReleaseEvent(QMouseEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#10 0x73669ce8 in QWidget::event(QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#11 0x7361a11c in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x736209be in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x72d9f86d in QCoreApplication::notifyInternal(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#14 0x7362007f in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#15 0x73695bde in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#16 0x73695477 in QApplication::x11ProcessEvent(_XEvent*) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#17 0x736bd432 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#18 0x7fffee3ebc5d in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x7fffee3ebf48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x7fffee3ebffc in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x72dcd031 in
QEventDispatcherGlib::processEvents(QFlags)
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#22 0x736bd4e6 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#23 0x72d9e4f1 in
QEventLoop::processEvents(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#24 0x72d9e805 in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#25 0x72da3f67 in QCoreApplication::exec() () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#26 0x0043482a in main (argc=1, argv=0x7fffdeb8) at
../main.cpp:63
And the line calling strdup (in case my sources are slightly off sync):
if (!same_string(displayedTrip.location,
currentTrip->location)) {
currentTrip->location =
strdup(displayedTrip.location);
mark_divelist_changed(true);
}
Reproduction steps:
- start new divelog
- import dives/test0.xml-test38.xml
- select the trip on top of the divelist
- edit notes
- save
BTW if I modify the trip location before saving, no crash.
miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
