Re: Segfault when trying to edit cylinder information - solved!

On 14 June 2017 at 01:31, Pedro Neves wrote: > On 13-06-2017 23:19, Lubomir I. Ivanov wrote: > > git apply test_tank_info_model_fix.patch > > Lubomir: > > After applying your patch it all works as supposed. I can edit cylinder info > without any problems. > > Thanks a lot! >

[PATCH] tankinfomodel.cpp: clamp row index to [0 - MAX_TANK_INFO]

From: "Lubomir I. Ivanov" MAX_TANK_INFO is a new macro in dive.h to define the maximum number of tank_info_t objects. TankInfoModel's data() and setData() now check for valid row indexes before accessing the tank_info[] array directly. Without this patch

Re: Segfault when trying to edit cylinder information - solved!

On 13-06-2017 23:19, Lubomir I. Ivanov wrote: git apply test_tank_info_model_fix.patch Lubomir: After applying your patch it all works as supposed. I can edit cylinder info without any problems. Thanks a lot! Cheers: Pedro ___ subsurface

Re: Segfault when trying to edit cylinder information

On 14 June 2017 at 01:01, Pedro Neves wrote: > On 13-06-2017 22:43, Lubomir I. Ivanov wrote: > > replace it with the following: > const int test_row = index.row(); > fprintf(stderr, "TEST_ROW: %d\n", test_row); // include if needed > struct tank_info_t *info =

Re: Segfault when trying to edit cylinder information

On 13-06-2017 22:43, Lubomir I. Ivanov wrote: replace it with the following: const int test_row = index.row(); fprintf(stderr, "TEST_ROW: %d\n", test_row); // include if needed struct tank_info_t *info = _info[test_row]; Lubomir: This is what I get now: TEST_ROW: 0 TEST_ROW: 0 TEST_ROW: 0

Re: Segfault when trying to edit cylinder information

On 13 June 2017 at 23:58, Thiago Macieira wrote: > On terça-feira, 13 de junho de 2017 13:16:21 PDT Lubomir I. Ivanov wrote: >> i cannot reproduce the problem, but also the above should not happen >> as we allocate the cylinder "type" (tank_info_t->name) on the heap and >>

Re: Segfault when trying to edit cylinder information

On 14 June 2017 at 00:30, Pedro Neves wrote: > Lubomir: > > On 13-06-2017 21:16, Lubomir I. Ivanov wrote: >> >> >> random questions: >> - are you running from an app-image or is this your build? > > It happens both with my build and with the appimage it's good that you are

Re: Segfault when trying to edit cylinder information

Lubomir: On 13-06-2017 21:16, Lubomir I. Ivanov wrote: random questions: - are you running from an app-image or is this your build? It happens both with my build and with the appimage - which OS / subsurface version? Arch Linux / Latest from master or with 4.6.4 appimage - does it happen

Re: Segfault when trying to edit cylinder information

On terça-feira, 13 de junho de 2017 13:16:21 PDT Lubomir I. Ivanov wrote: > i cannot reproduce the problem, but also the above should not happen > as we allocate the cylinder "type" (tank_info_t->name) on the heap and > it's address cannot be so low (0x1770). It comes from:

Re: Segfault when trying to edit cylinder information

On 13 June 2017 at 22:38, Pedro Neves wrote: > > #0 0x7fffef3b51a6 in strlen () at /usr/lib/libc.so.6 > #1 0x005a5c33 in QString::QString(char const*) > (this=0x7fffcbd0, ch=0x1770 0x1770>) at /usr/include/qt/QtCore/qstring.h:659 > #2 0x0072e14d

Re: Segfault when trying to edit cylinder information

On 13-06-2017 19:14, Thiago Macieira wrote: type 'bt" when you get above. Thiago, my bad ;-) (gdb) bt #0 0x7fffef3b51a6 in strlen () at /usr/lib/libc.so.6 #1 0x005a5c33 in QString::QString(char const*) (this=0x7fffcbd0, ch=0x1770 0x1770>) at

Re: Bug: VPMB profile on latest executable

On 13/06/2017 09:35, Robert Helling wrote: Willem, On 13. Jun 2017, at 07:46, Willem Ferguson > wrote: Running on V4.6.4-188-gbe8 on Ubuntu 16.04, there appears to be a problem with representing the VPM-B ceiling on

Segfault when trying to edit cylinder information

Hi all: I've been facing a segfault with Subsurface each time I try to insert cylinder information of my dives. After I download my new dives, I'm able to fill the Start press., End press, the Work press. and the O2%. But when I click the Type or Size, I get a segfault. This happens both

Re: ASSERT: "bytes <= bufferSize" in file tools/qringbuffer.cpp, line 74

On 13 June 2017 at 17:08, Thiago Macieira wrote: > On terça-feira, 13 de junho de 2017 03:09:51 PDT Linus Torvalds wrote: >> I seem to be the only one getting this, and I don't get it reliably >> either. It seems to be timing-related somehow, because it never >> happens under

Re: [PATCH] MultiFilter: make sure to uncheck "Filter divelist" if the user closes

I can breath again, and I'm currently looking at this. On Tue, Jun 13, 2017 at 1:30 PM, Lubomir I. Ivanov wrote: > On 13 June 2017 at 05:28, Dirk Hohndel wrote: > > On Tue, Jun 13, 2017 at 01:18:57AM +0300, Lubomir I. Ivanov wrote: > >> > > > > Change

Re: ASSERT: "bytes <= bufferSize" in file tools/qringbuffer.cpp, line 74

On terça-feira, 13 de junho de 2017 03:09:51 PDT Linus Torvalds wrote: > I seem to be the only one getting this, and I don't get it reliably > either. It seems to be timing-related somehow, because it never > happens under gdb, but I *can* catch it with a core-dump and then get > gdb to show me

Re: ASSERT: "bytes <= bufferSize" in file tools/qringbuffer.cpp, line 74

On 13 June 2017 at 13:09, Linus Torvalds wrote: > #14 0x7fa0764abe8b in Marble::MarbleModel::setMapThemeId(QString > const&) () from > /home/torvalds/src/install-root/lib/libssrfmarblewidget.so.21 looks very similar to a recent setMapThemId() related breakage

Re: [PATCH] MultiFilter: make sure to uncheck "Filter divelist" if the user closes

On 13 June 2017 at 05:28, Dirk Hohndel wrote: > On Tue, Jun 13, 2017 at 01:18:57AM +0300, Lubomir I. Ivanov wrote: >> > > Change looks reasonable to me. What I don't see is why this would get an > assert. > > Tomaz, any idea? > the change is not directly related to the assert

ASSERT: "bytes <= bufferSize" in file tools/qringbuffer.cpp, line 74

I seem to be the only one getting this, and I don't get it reliably either. It seems to be timing-related somehow, because it never happens under gdb, but I *can* catch it with a core-dump and then get gdb to show me where it is. Backtrace appended in case it makes anybody go "yeah". This may be

new binaries with latest libdivecomputer as well

A full set of test builds is up that contains Linus' first draft of Scubapro G2 support. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface