[Marble-devel] Marble crash when you scrolling a map in "Flat Map" projection

Tue Dec 18 13:55:18 UTC 2012

Hi ,Torsten

   During the Bug with Marble crash investigation I have found, that the
guardians on the functions StackedTile::pixel(...) and
StackedTile::pixelF(...) make the bug unreproducible only when Marble is
built on a debug. If you build Marble on release mode, the bug begins to
reproduce again.

gdb log:

[Thread 0xa7234b40 (LWP 22713) exited]
[Thread 0xaabfcb40 (LWP 22712) exited]
[Thread 0xb17feb40 (LWP 22711) exited]
[Thread 0xb6116b40 (LWP 22714) exited]
[New Thread 0xb6116b40 (LWP 22715)]
[New Thread 0xb17feb40 (LWP 22716)]
[New Thread 0xaabfcb40 (LWP 22717)]
[New Thread 0xa7234b40 (LWP 22718)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa7234b40 (LWP 22718)]
0x012add16 in Marble::StackedTile::pixel(int, int) const () from
/usr/local/lib/libmarblewidget.so.15
(gdb) quit

Could you tell me what treads are run when you scroll the map and change
zoom?

2012/12/18 Torsten Rahn <tackat at t-online.de>

>
> Hi,
>
> I can confirm this crash happening in master - however even on a pretty
> speedy
> machine.
>
> It happened to me about  a week ago when I did pretty much what you
> described
> (zooming while panning at the top of the flat map projection).
> I also looked at the backtrace back then and also figured that the allowed
> range of values for the position in the tile had been exceeded.
>
> I didn't have enough time to investigate it further though.
>
> I guess it has been there since the inertial panning has been there:
>
> The Texturerendering assumes rendering to happen within the same zoom level
> (unless it becomes aware that it has changed).
> I suspect that the combination of threaded rendering, changing zoom level
> while panning and the access of pixels near the pole area exposes a corner
> case which leads to the problem you mention.
>
> It would be nice if this problem could be understood in a better way. Oleg:
> could you look into it?
>
> Nevertheless I think it it would be a good  idea to introduce "guards"
> inside
> pixel() an pixelF() the way you suggest them in your patch:
>
> However the actual lines should include include an "else":
>
> if (x < 0) x = 0;
> else if (x > m_resultTile.width()) x = m_resultTile.width();
>
> if (y < 0) y = 0;
> else if (y > m_resultTile.height()) y = m_resultTile.height();
>
> I suspect that this might also get rid of the random crashes that we have
> seen
> on the mobile version.
> In terms of render quality the user will not notice the "wrong values"
> since
> they only affect very few pixels. It might or might not make sense to
> switch
> these guards off during the development of Marble.
>
> Best Regards,
> Torsten
>
>
> On Dienstag, 18. Dezember 2012 07:33:41 Олег Любимов wrote:
> > Hi all.
> >
> > Marble crashes when you scroll a map and change zoom level in the "Flat
> > Map" projection. This bug has reproducing probability 80-90% (100% if you
> > use slow hardware). The bug is reproduced on Desktop and on QML marble
> > application.
> > Reproducing:
> > 1. Download sources, build(QT only, Debug), install and run marble
> > 2. Check a map witch has tile level more than 1. I checked "Historical
> Map
> > 1689"
> >  3. When the map is opened, set a Projection to "Flat Map" set zoom to
> > minimum, and drag the map (it will be looked sush as a tape) to the Top
> > Bourder (or Bottom Bourder) of Marble Widget.
> > 4. Press left mouse and scroll the map from left to right (the map should
> > scrolling by "inertia" several seconds after you release left mouse
> button)
> > 5. When the will be scrolling by "inertia", you should increase or
> decrease
> > zoom of the map and grag it from Top to Bottom(Bottom to Top).
> > 6. After several reps of the 4 and 5 steps the Error should be accours.
> > Sometimes is reproduce in the first rep, but often you should make 5 - 20
> > reps of 4 and 5 steps.
> >
> > Marble version is 1.4.9 (1.5.0 RC 1) Operating system Xubuntu 11.10 Qt
> > version 4.8.1
> >
> > Does anybody have this
> > problem?(https://bugs.kde.org/show_bug.cgi?id=311624)
> >
> > ------- GDB
> >
> log------------------------------------------------------------------------
> >
> ---------------------------------------------------------------------------
> > ------------------------------------------------- Program received signal
> > SIGSEGV, Segmentation fault.
> > [Switching to Thread 0xb3bffb40 (LWP 17144)]
> > Marble::StackedTile::pixel (this=0xb3d0c3f8, x=559, y=-2027) at
> > /home/olyubimov/git_repository/marble/src/lib/StackedTile.cpp:262
> > 262 return d->pixel( x, y );
> > (gdb) ba
> > #0 Marble::StackedTile::pixel (this=0xb3d0c3f8, x=559, y=-2027) at
> > /home/olyubimov/git_repository/marble/src/lib/StackedTile.cpp:262
> > #1 0x012b6f22 in Marble::ScanlineTextureMapperContext::pixelValueApprox
> > (this=0xb3bff1ec, lon=-0.90835936550699259, lat=1.5724603059378008,
> > scanLine=<optimized out>, n=8) at
> >
> /home/olyubimov/git_repository/marble/src/lib/ScanlineTextureMapperContext.
> > cpp:338 #2 0x012b9245 in
> > Marble::EquirectScanlineTextureMapper::RenderJob::run (this=0x89dbb90)
> > at
> >
> /home/olyubimov/git_repository/marble/src/lib/EquirectScanlineTextureMapper
> > .cpp:231 #3 0x0018d39b in QThreadPoolThread::run (this=0x8b9a2a0) at
> > concurrent/qthreadpool.cpp:107
> > #4 0x0019ade0 in QThreadPrivate::start (arg=0x8b9a2a0) at
> > thread/qthread_unix.cpp:298
> > #5 0x0179fd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> > #6 0x016ddd3e in clone () from /lib/i386-linux-gnu/libc.so.6
> >
> ---------------------------------------------------------------------------
> >
> ---------------------------------------------------------------------------
> > ----------------------------------------------------------------- I my
> > personal opinion this bug is generated when function
> > Marble::StackedTile::pixel (this=0xb3d0c3f8, x=559, y=-2027) takes
> > arguments with invalid values. I create simple patch (see attachment) to
> > add code, which limits the arguments. Because "x" and "y" args are the
> > pixel values the bottom bound or this args is 0, and the top bounds of
> the
> > args is QImage m_resultTile.width() and QImage m_resultTile.heidth(). If
> > you limit the "x" and "y" args by this bounds the bug not reproduces.
> >
> > <http://postimage.org/image/5h0b2pf4r/>
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20121218/73eb76be/attachment.html>