bug milestones

[Georg Baum]

Hi,

currently we have 35 open bugs with 2.1.3 milestone. None of them will be 
fixed for 2.1.3, since the release is frozen, so these bugs need to be 
retargeted soon. Many of these bugs were already retargeted for several 
times (like 2.1.0 - 2.1.1 - 2.1.2 - 2.1.3). This somehow renders the 
milestone a bit useless, since a milestone does not really mean that a bug 
gets fixed for that release. IMHO we should rethink our bug targeting 
practice, and I would propose the following:

Only set a fixed milestone (like 2.1.4 or 2.2.0) if a) somebody is actively 
working on a fix or b) the bug is so severe that it would block the release 
if it is not fixed. If a bug is important, but nobody is working on it, and 
it is no shostopper, use a milestone like 2.1.x or 2.2.x. For all other 
bugs, do not set a milestone at all.

I believe that such a policy would make the milestones more useful, both for 
users and developers, and that they would show a more realistic picture (not 
too many bugs get fixed with a small number of developers). It would also 
reduce the number of milestone changes. What do you think?


Georg

Re: Source Tarballs for 2.1.3

[Liviu Andronic]

On Fri, Feb 6, 2015 at 2:40 AM, Richard Heck rgh...@lyx.org wrote:

 Source tarballs for 2.1.3 can be found here:
 ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
 Please prepare binaries by Monday. I'd like to do the release on Tuesday.

Compiles just fine on Ubuntu:


LyX 2.1.3 (2014-02-05)
Built on Feb 7 2015, 09:56:50
Configuration
Host type: x86_64-pc-linux-gnu
Special build flags: build=release warnings use-aspell use-enchant use-hunspell
C++ Compiler: g++ (4.8)
C++ Compiler LyX flags:
C++ Compiler flags: -Wextra -Wall -O2
Linker flags:
Linker user flags:
Qt 4 Frontend:
Qt 4 version: 4.8.6
Packaging: posix
LyX binary dir: /usr/bin
LyX files dir: /usr/share/lyx


Liviu


 Richard




-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: bug milestones

[Jean-Marc Lasgouttes]

Le 07/02/15 10:04, Georg Baum a écrit :

Only set a fixed milestone (like 2.1.4 or 2.2.0) if a) somebody is actively
working on a fix or b) the bug is so severe that it would block the release
if it is not fixed. If a bug is important, but nobody is working on it, and
it is no shostopper, use a milestone like 2.1.x or 2.2.x. For all other
bugs, do not set a milestone at all.


Yes, this makes sense to me.

JMarc

Re: Yet more static analysis: Use Coverity?

[Georg Baum]

Liviu Andronic wrote:

 Dear all,
 Following on this very old proposal, I went ahead and submitted the
 LyX code for static analysis to Coverity:
 https://scan.coverity.com/projects/4164

This looks very interesting, thank you very much!


Georg

Re: Yet more static analysis: Use Coverity?

[Cyrille Artho]

Hi all,
It's a good idea to look at these reports from time to time.

Note that usually some of the defects reported by static analysis are 
false positives; they may actually work as intended in the code due to 
the way a particular part of code behaves at run-time.


Sometimes it's possible to rewrite the code slightly to eliminate false 
positives; in many cases, slightly changing the code may also make it 
easier for humans to understand, not just for Coverity.


As we've found various memory corruption bugs only by testing, it's 
definitely a good idea to ensure that the warnings are fixed over time. 
Hopefully this will make some of the more elusive bugs we've had, a 
thing of the past.



Liviu Andronic wrote:

Dear all,
Following on this very old proposal, I went ahead and submitted the
LyX code for static analysis to Coverity:
https://scan.coverity.com/projects/4164

Coverity has uncovered ~250 implementation defects in the LyX code
base, with 10 or so of high severity (memory corruption, resource
leaks, etc.) To view the defects, you need to connect with your Github
account (or create one with Coverity) and request 'Add me to project'
(which I shall then approve). Coverity provides overall metrics like
defect density (LyX scores a respectable 0.53), but also classifies
uncovered bugs by type and severity, and provides a nice UI trying to
explain to the devels the specifics of the bug and how to address it
(e.g. where it happens, why it's an issue, etc.)

This tool is being used by heavy-hitters like LibreOffice, Linux
Kernel, Firefox or Python to improve the robustness of their code
base. I suspect that Coverity could prove invaluable when trying to
hunt down frustrating implementation issues like
http://www.lyx.org/trac/ticket/8854 or
http://www.lyx.org/trac/ticket/9049 .

In any case the identified bugs are now ready for inspection by the
devels, so feel free to drop by!

Regards,
Liviu


On Wed, Feb 24, 2010 at 6:52 PM, John McCabe-Dansted gma...@gmail.com wrote:

I found the errors reported by cppcheck much easier to fix than bug
reports (e.g. generated by my keytest). For example:
 [./development/lyxserver/server_monitor.c:173]: (error) Memory
leak: pipename
This had the obvious solution of adding free(pipename) to line 173.
Convincing myself that this fix was correct wasn't quite so trivial,
but still much easier than tracing down the cause of a traditional bug
report.

Unfortunately the cppcheck didn't seem very powerful and only found
bugs in code that was virtually unused.

My understanding is that Coverity is not only a much more powerful
check, but also focuses on making their bug reports easy to understand
and free of false-positives [1]. As such it seems that fixing many of
the bugs reported by Coverity would be trivial, and may even save time
as fixing dangerous code may close some of the hard to track down bugs
sitting in trac.

If we were to request that Coverity scan LyX would anyone either be
interested in either looking through the bugs, or having someone else
such as myself look through the bug reports? I understand that those
who wish to see the bug reports have to agree to a click through
license agreeing that if you produce a competing product to Coverity
you won't use any IP you learnt about Coverity from looking their
bug reports.

--
John C. McCabe-Dansted
[1] 
http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext






--
Regards,
Cyrille Artho - http://artho.com/
Those who will not reason, are bigots, those who cannot,
are fools, and those who dare not, are slaves.
-- George Gordon Noel Byron

Re: Yet more static analysis: Use Coverity?

[Liviu Andronic]

On Sat, Feb 7, 2015 at 3:32 PM, Cyrille Artho c.ar...@aist.go.jp wrote:
 Hi all,
 It's a good idea to look at these reports from time to time.

 Note that usually some of the defects reported by static analysis are false
 positives; they may actually work as intended in the code due to the way a
 particular part of code behaves at run-time.

Coverity has some facilities to deal with false positives.

For instance, it is possible to classify an identified issue as false
positive or intentional, meaning that Coverity shall ignore it in
future code scans. But more usefully we can specify a Modeling File:

Static code analysis has some limitations in its ability to
understand certain dynamic operations. This limitation may result in
falsely detecting defects. Since most false-positive defects are
caused by few functions in your code base, Coverity allows you to tell
the analysis engine to treat these functions differently. This is
called a Modeling File. By providing a modeling file, most projects
reduce their false-positive rate to the ballpark of 10%.

Cheers,
Liviu


 Sometimes it's possible to rewrite the code slightly to eliminate false
 positives; in many cases, slightly changing the code may also make it easier
 for humans to understand, not just for Coverity.

 As we've found various memory corruption bugs only by testing, it's
 definitely a good idea to ensure that the warnings are fixed over time.
 Hopefully this will make some of the more elusive bugs we've had, a thing of
 the past.



 Liviu Andronic wrote:

 Dear all,
 Following on this very old proposal, I went ahead and submitted the
 LyX code for static analysis to Coverity:
 https://scan.coverity.com/projects/4164

 Coverity has uncovered ~250 implementation defects in the LyX code
 base, with 10 or so of high severity (memory corruption, resource
 leaks, etc.) To view the defects, you need to connect with your Github
 account (or create one with Coverity) and request 'Add me to project'
 (which I shall then approve). Coverity provides overall metrics like
 defect density (LyX scores a respectable 0.53), but also classifies
 uncovered bugs by type and severity, and provides a nice UI trying to
 explain to the devels the specifics of the bug and how to address it
 (e.g. where it happens, why it's an issue, etc.)

 This tool is being used by heavy-hitters like LibreOffice, Linux
 Kernel, Firefox or Python to improve the robustness of their code
 base. I suspect that Coverity could prove invaluable when trying to
 hunt down frustrating implementation issues like
 http://www.lyx.org/trac/ticket/8854 or
 http://www.lyx.org/trac/ticket/9049 .

 In any case the identified bugs are now ready for inspection by the
 devels, so feel free to drop by!

 Regards,
 Liviu


 On Wed, Feb 24, 2010 at 6:52 PM, John McCabe-Dansted gma...@gmail.com
 wrote:

 I found the errors reported by cppcheck much easier to fix than bug
 reports (e.g. generated by my keytest). For example:
  [./development/lyxserver/server_monitor.c:173]: (error) Memory
 leak: pipename
 This had the obvious solution of adding free(pipename) to line 173.
 Convincing myself that this fix was correct wasn't quite so trivial,
 but still much easier than tracing down the cause of a traditional bug
 report.

 Unfortunately the cppcheck didn't seem very powerful and only found
 bugs in code that was virtually unused.

 My understanding is that Coverity is not only a much more powerful
 check, but also focuses on making their bug reports easy to understand
 and free of false-positives [1]. As such it seems that fixing many of
 the bugs reported by Coverity would be trivial, and may even save time
 as fixing dangerous code may close some of the hard to track down bugs
 sitting in trac.

 If we were to request that Coverity scan LyX would anyone either be
 interested in either looking through the bugs, or having someone else
 such as myself look through the bug reports? I understand that those
 who wish to see the bug reports have to agree to a click through
 license agreeing that if you produce a competing product to Coverity
 you won't use any IP you learnt about Coverity from looking their
 bug reports.

 --
 John C. McCabe-Dansted
 [1]
 http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext





 --
 Regards,
 Cyrille Artho - http://artho.com/
 Those who will not reason, are bigots, those who cannot,
 are fools, and those who dare not, are slaves.
 -- George Gordon Noel Byron



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: Source Tarballs for 2.1.3

[Stephan Witt]

Am 06.02.2015 um 02:40 schrieb Richard Heck rgh...@lyx.org:

 Source tarballs for 2.1.3 can be found here:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
 Please prepare binaries by Monday. I'd like to do the release on Tuesday.
 
 Richard
 

Configuration
  Host type:x86_64-apple-darwin12.6.0
  Special build flags:  build=release warnings use-aspell use-hunspell
  C++ Compiler: g++ (4.2.1)
  C++ Compiler LyX flags:
  C++ Compiler flags:
-I/Users/stephan/git/lyx-build/utilities/include  -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
 -arch x86_64 -mmacosx-version-min=10.6 -Os
  Linker flags: 
  Linker user flags: -L/Users/stephan/git/lyx-build/utilities/lib 
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
 -arch x86_64 -mmacosx-version-min=10.6
  Qt 4 Frontend:
  Qt 4 version: 4.8.6
  Packaging:macosx
  LyX binary dir:   
/Users/stephan/git/lyx-build/LyX-2.1.3.app/Contents/MacOS
  LyX files dir:
/Users/stephan/git/lyx-build/LyX-2.1.3.app/Contents/Resources

It compiles and runs on Mac OS X too.

Stephan

Re: bug milestones

[Jürgen Spitzmüller]

Am Samstag 07 Februar 2015, 13:13:43 schrieb Jean-Marc Lasgouttes:
 Le 07/02/15 10:04, Georg Baum a écrit :
  Only set a fixed milestone (like 2.1.4 or 2.2.0) if a) somebody is
  actively
  working on a fix or b) the bug is so severe that it would block the
  release
  if it is not fixed. If a bug is important, but nobody is working on it,
  and
  it is no shostopper, use a milestone like 2.1.x or 2.2.x. For all other
  bugs, do not set a milestone at all.
 
 Yes, this makes sense to me.

I would be fine with that, too.

Jürgen

 JMarc

AW: Source Tarballs for 2.1.3

[Uwe Stöhr]

Source tarballs for 2.1.3 can be found here:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
Please prepare binaries by Monday. I'd like to do the release on Tuesday.

‎Hi Richard,

It compiles fine on Windows. I think I can provide the installers on Monday. 

Regards Uwe 

reporting a bug (Mac OSX Mavericks)

[Vadim Marmer]

It happens every other time I quit LyX

Process: lyx [31542]
Path:/Applications/LyX.app/Contents/MacOS/lyx
Identifier:  org.lyx.lyx
Version: 2.1.1 (???)
Code Type:   X86-64 (Native)
Parent Process:  launchd [180]
Responsible: lyx [31542]
User ID: 501

Date/Time:   2015-02-07 12:44:17.119 -0800
OS Version:  Mac OS X 10.9.5 (13F34)
Report Version:  11
Anonymous UUID:  D69293EA-F826-0FAA-CBF7-B45C975F83F7

Sleep/Wake UUID: F2BC8F60-282D-4C06-AE54-19D707587B9D

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0010

VM Regions Near 0x10:
-- 
__TEXT 0001-0001008dd000 [ 9076K] r-x/rwx 
SM=COW  /Applications/LyX.app/Contents/MacOS/lyx

Application Specific Information:
abort() called
*** error for object 0x10400b338: pointer being freed was not allocated
 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff985a0866 __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fff8c9b235c pthread_kill + 92
2   libsystem_c.dylib   0x7fff8af4ab1a abort + 125
3   libsystem_malloc.dylib  0x7fff8add107f free + 411
4   QtGui   0x000101382f90 cleanup_mimes() + 112
5   QtCore  0x0001010fa165 
qt_call_post_routines() + 101
6   QtGui   0x0001013299f7 
QApplication::~QApplication() + 105
7   org.lyx.lyx 0x0001002eac0e 
lyx::frontend::noAppDialog(QString const, QString const, QMessageBox::Icon) + 
178
8   org.lyx.lyx 0x0001002e9ba2 
lyx::frontend::Alert::doError(std::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t  const, 
std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t  
const, bool) + 452
9   org.lyx.lyx 0x0001002e99b3 
lyx::frontend::Alert::error(std::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t  const, 
std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t  
const, bool) + 101
10  org.lyx.lyx 0x0001000eca2c error_handler + 478
11  libsystem_platform.dylib0x7fff8d00f5aa _sigtramp + 26
12  libobjc.A.dylib 0x7fff91ad462a (anonymous 
namespace)::AutoreleasePoolPage::pop(void*) + 454
13  com.apple.CoreFoundation0x7fff8fe7a932 
_CFAutoreleasePoolPop + 50
14  com.apple.Foundation0x7fff8bcc054c -[NSAutoreleasePool 
release] + 140
15  org.lyx.lyx 0x0001004ec0db 
closeAllLinkBackLinks + 59
16  org.lyx.lyx 0x0001002f28c2 
lyx::frontend::GuiApplication::~GuiApplication() + 36
17  org.lyx.lyx 0x0001000edc61 
lyx::LyX::prepareExit() + 1133
18  org.lyx.lyx 0x0001000f0da0 lyx::LyX::exec(int, 
char**) + 1626
19  org.lyx.lyx 0x00011f82 main + 70
20  org.lyx.lyx 0x00011f34 start + 52

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib  0x7fff985a1662 kevent64 + 10
1   libdispatch.dylib   0x7fff94148421 _dispatch_mgr_invoke 
+ 239
2   libdispatch.dylib   0x7fff94148136 _dispatch_mgr_thread 
+ 52

Thread 2:: com.apple.CFSocket.private
0   libsystem_kernel.dylib  0x7fff985a09aa __select + 10
1   com.apple.CoreFoundation0x7fff8fefea03 __CFSocketManager + 
867
2   libsystem_pthread.dylib 0x7fff8c9b1899 _pthread_body + 138
3   libsystem_pthread.dylib 0x7fff8c9b172a _pthread_start + 137
4   libsystem_pthread.dylib 0x7fff8c9b5fc9 thread_start + 13

Thread 3:
0   libsystem_kernel.dylib  0x7fff9859ca1a mach_msg_trap + 10
1   libsystem_kernel.dylib  0x7fff9859bd18 mach_msg + 64
2   com.apple.CoreFoundation0x7fff8feb2f15 
__CFRunLoopServiceMachPort + 181
3   com.apple.CoreFoundation0x7fff8feb2539 __CFRunLoopRun + 1161
4   com.apple.CoreFoundation0x7fff8feb1e75 CFRunLoopRunSpecific 
+ 309
5   com.apple.AppKit0x7fff9229505e _NSEventThread + 144
6   libsystem_pthread.dylib 0x7fff8c9b1899 _pthread_body + 138
7   libsystem_pthread.dylib 0x7fff8c9b172a _pthread_start + 137
8   libsystem_pthread.dylib 0x7fff8c9b5fc9 thread_start + 13

Thread 4:: QProcessManager
0   libsystem_kernel.dylib  0x7fff985a09aa __select + 10
1   QtCore  0x0001010d802e 
QProcessManager::run() + 218
2   QtCore  0x000101021d0a 
QThreadPrivate::start(void*) + 490
3 

Re: Yet more static analysis: Use Coverity?

[Jean-Marc Lasgouttes]

Le 07/02/15 03:41, Liviu Andronic a écrit :

Dear all,
Following on this very old proposal, I went ahead and submitted the
LyX code for static analysis to Coverity:
https://scan.coverity.com/projects/4164

Coverity has uncovered ~250 implementation defects in the LyX code
base, with 10 or so of high severity (memory corruption, resource
leaks, etc.) To view the defects, you need to connect with your Github
account (or create one with Coverity) and request 'Add me to project'
(which I shall then approve). Coverity provides overall metrics like
defect density (LyX scores a respectable 0.53), but also classifies
uncovered bugs by type and severity, and provides a nice UI trying to
explain to the devels the specifics of the bug and how to address it
(e.g. where it happens, why it's an issue, etc.)


That is really a great idea. Lots of things to fix, yum!

JMarc

Re: AW: Source Tarballs for 2.1.3

[Richard Heck]

On 02/07/2015 12:24 PM, Uwe Stöhr wrote:

Source tarballs for 2.1.3 can be found here:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
Please prepare binaries by Monday. I'd like to do the release on Tuesday.

‎Hi Richard,

It compiles fine on Windows. I think I can provide the installers on Monday.


OK. Please note that the date was wrong in the original tarball: 2014 
instead of 2015. I uploaded a new one earlier today.


Richard

Re: Yet more static analysis: Use Coverity?

[Liviu Andronic]

On Sat, Feb 7, 2015 at 10:31 PM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 07/02/15 03:41, Liviu Andronic a écrit :

 Dear all,
 Following on this very old proposal, I went ahead and submitted the
 LyX code for static analysis to Coverity:
 https://scan.coverity.com/projects/4164

 Coverity has uncovered ~250 implementation defects in the LyX code
 base, with 10 or so of high severity (memory corruption, resource
 leaks, etc.) To view the defects, you need to connect with your Github
 account (or create one with Coverity) and request 'Add me to project'
 (which I shall then approve). Coverity provides overall metrics like
 defect density (LyX scores a respectable 0.53), but also classifies
 uncovered bugs by type and severity, and provides a nice UI trying to
 explain to the devels the specifics of the bug and how to address it
 (e.g. where it happens, why it's an issue, etc.)


 That is really a great idea. Lots of things to fix, yum!

Yay! Glad you all like it! :)

I propose that whenever someone finds some item particularly yummy,
and they start looking more closely into the issue, that they
nominally assign themselves to that item so that others would know
that someone is already working on it. (OK, that was unnecessarily
verbose, even if surprisingly precise, but I hope it's excusable given
that it's quite late here...)

Cheers,
Liviu


 JMarc




-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

View/compile reduced size PDF within LyX

[James]

Is there any reason that an option within LyX to view or compile a reduced
size PDF?

For example, writing a graphic heavy document such as a thesis, which
includes large numbers of HQ photos, bitmaps, vector graphics that have
embedded raster images, can result in very large PDF files.

The PDF is no doubt the the most frequently used output, but when the files
are large they re hugely inconvenient to handle and distribute. Large PDFs
are not handled well by all machines and and can make use of them
difficult. This is especially the case when the PDF is going to be marked
up using a PDF editor and extra notes, comments and editorial additional
are added.

To reduce the PDF to a sensible size for markup, I use ghostscript at the
command line to reduce the PDF to a size suitable for markup
distribution (initially
learnt from
http://tex.stackexchange.com/questions/14429/pdftex-reduce-pdf-size-reduce-image-quality
). However, not everyone who uses LyX is comfortable using shell commands.
It would seem to be an unnecessary step to have to do this externally when
ghostscript is already required as part of the LyX installation to create
postscript files.

It would be great to see a button or Document menu item that gave an option
to view/compile in a reduced size by with ghostscript and setting the
-dPDFSETTINGS
 switch to one of the following
/screen (72dpi), /ebook (150dpi), /printer (300dpi), /prepress (300dpi),
/default.

Full command:
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook
-dNOPAUSE -dQUIET -dBATCH -sOutputFile=small.pdf big.pdf

 How hard is this to implement? Is there a reason why such
an option doesn't already exist?

Cheers
James

bug milestones

[Georg Baum]

Hi,

currently we have 35 open bugs with 2.1.3 milestone. None of them will be 
fixed for 2.1.3, since the release is frozen, so these bugs need to be 
retargeted soon. Many of these bugs were already retargeted for several 
times (like 2.1.0 -> 2.1.1 -> 2.1.2 -> 2.1.3). This somehow renders the 
milestone a bit useless, since a milestone does not really mean that a bug 
gets fixed for that release. IMHO we should rethink our bug targeting 
practice, and I would propose the following:

Only set a fixed milestone (like 2.1.4 or 2.2.0) if a) somebody is actively 
working on a fix or b) the bug is so severe that it would block the release 
if it is not fixed. If a bug is important, but nobody is working on it, and 
it is no shostopper, use a milestone like 2.1.x or 2.2.x. For all other 
bugs, do not set a milestone at all.

I believe that such a policy would make the milestones more useful, both for 
users and developers, and that they would show a more realistic picture (not 
too many bugs get fixed with a small number of developers). It would also 
reduce the number of milestone changes. What do you think?


Georg

Re: Yet more static analysis: Use Coverity?

[Georg Baum]

Liviu Andronic wrote:

> Dear all,
> Following on this very old proposal, I went ahead and submitted the
> LyX code for static analysis to Coverity:
> https://scan.coverity.com/projects/4164

This looks very interesting, thank you very much!


Georg

Re: Source Tarballs for 2.1.3

[Liviu Andronic]

On Fri, Feb 6, 2015 at 2:40 AM, Richard Heck  wrote:
>
> Source tarballs for 2.1.3 can be found here:
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
> Please prepare binaries by Monday. I'd like to do the release on Tuesday.
>
Compiles just fine on Ubuntu:


LyX 2.1.3 (2014-02-05)
Built on Feb 7 2015, 09:56:50
Configuration
Host type: x86_64-pc-linux-gnu
Special build flags: build=release warnings use-aspell use-enchant use-hunspell
C++ Compiler: g++ (4.8)
C++ Compiler LyX flags:
C++ Compiler flags: -Wextra -Wall -O2
Linker flags:
Linker user flags:
Qt 4 Frontend:
Qt 4 version: 4.8.6
Packaging: posix
LyX binary dir: /usr/bin
LyX files dir: /usr/share/lyx


Liviu


> Richard
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: bug milestones

[Jean-Marc Lasgouttes]

Le 07/02/15 10:04, Georg Baum a écrit :

Only set a fixed milestone (like 2.1.4 or 2.2.0) if a) somebody is actively
working on a fix or b) the bug is so severe that it would block the release
if it is not fixed. If a bug is important, but nobody is working on it, and
it is no shostopper, use a milestone like 2.1.x or 2.2.x. For all other
bugs, do not set a milestone at all.


Yes, this makes sense to me.

JMarc

Re: Source Tarballs for 2.1.3

[Stephan Witt]

Am 06.02.2015 um 02:40 schrieb Richard Heck :

> Source tarballs for 2.1.3 can be found here:
>ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
> Please prepare binaries by Monday. I'd like to do the release on Tuesday.
> 
> Richard
> 

Configuration
  Host type:x86_64-apple-darwin12.6.0
  Special build flags:  build=release warnings use-aspell use-hunspell
  C++ Compiler: g++ (4.2.1)
  C++ Compiler LyX flags:
  C++ Compiler flags:
-I/Users/stephan/git/lyx-build/utilities/include  -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
 -arch x86_64 -mmacosx-version-min=10.6 -Os
  Linker flags: 
  Linker user flags: -L/Users/stephan/git/lyx-build/utilities/lib 
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
 -arch x86_64 -mmacosx-version-min=10.6
  Qt 4 Frontend:
  Qt 4 version: 4.8.6
  Packaging:macosx
  LyX binary dir:   
/Users/stephan/git/lyx-build/LyX-2.1.3.app/Contents/MacOS
  LyX files dir:
/Users/stephan/git/lyx-build/LyX-2.1.3.app/Contents/Resources

It compiles and runs on Mac OS X too.

Stephan

Re: Yet more static analysis: Use Coverity?

[Cyrille Artho]

Hi all,
It's a good idea to look at these reports from time to time.

Note that usually some of the defects reported by static analysis are 
"false positives"; they may actually work as intended in the code due to 
the way a particular part of code behaves at run-time.


Sometimes it's possible to rewrite the code slightly to eliminate false 
positives; in many cases, slightly changing the code may also make it 
easier for humans to understand, not just for Coverity.


As we've found various memory corruption bugs only by testing, it's 
definitely a good idea to ensure that the warnings are fixed over time. 
Hopefully this will make some of the more elusive bugs we've had, a 
thing of the past.



Liviu Andronic wrote:

Dear all,
Following on this very old proposal, I went ahead and submitted the
LyX code for static analysis to Coverity:
https://scan.coverity.com/projects/4164

Coverity has uncovered ~250 implementation defects in the LyX code
base, with 10 or so of high severity (memory corruption, resource
leaks, etc.) To view the defects, you need to connect with your Github
account (or create one with Coverity) and request 'Add me to project'
(which I shall then approve). Coverity provides overall metrics like
defect density (LyX scores a respectable 0.53), but also classifies
uncovered bugs by type and severity, and provides a nice UI trying to
explain to the devels the specifics of the bug and how to address it
(e.g. where it happens, why it's an issue, etc.)

This tool is being used by heavy-hitters like LibreOffice, Linux
Kernel, Firefox or Python to improve the robustness of their code
base. I suspect that Coverity could prove invaluable when trying to
hunt down frustrating implementation issues like
http://www.lyx.org/trac/ticket/8854 or
http://www.lyx.org/trac/ticket/9049 .

In any case the identified bugs are now ready for inspection by the
devels, so feel free to drop by!

Regards,
Liviu


On Wed, Feb 24, 2010 at 6:52 PM, John McCabe-Dansted  wrote:

I found the errors reported by cppcheck much easier to fix than bug
reports (e.g. generated by my keytest). For example:
 [./development/lyxserver/server_monitor.c:173]: (error) Memory
leak: pipename
This had the obvious solution of adding free(pipename) to line 173.
Convincing myself that this fix was correct wasn't quite so trivial,
but still much easier than tracing down the cause of a traditional bug
report.

Unfortunately the cppcheck didn't seem very powerful and only found
bugs in code that was virtually unused.

My understanding is that Coverity is not only a much more powerful
check, but also focuses on making their bug reports easy to understand
and free of false-positives [1]. As such it seems that fixing many of
the bugs reported by Coverity would be trivial, and may even save time
as fixing dangerous code may close some of the hard to track down bugs
sitting in trac.

If we were to request that Coverity scan LyX would anyone either be
interested in either looking through the bugs, or having someone else
such as myself look through the bug reports? I understand that those
who wish to see the bug reports have to agree to a click through
license agreeing that if you produce a competing product to Coverity
you won't use any "IP" you learnt about Coverity from looking their
bug reports.

--
John C. McCabe-Dansted
[1] 
http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext






--
Regards,
Cyrille Artho - http://artho.com/
Those who will not reason, are bigots, those who cannot,
are fools, and those who dare not, are slaves.
-- George Gordon Noel Byron

Re: Yet more static analysis: Use Coverity?

[Liviu Andronic]

On Sat, Feb 7, 2015 at 3:32 PM, Cyrille Artho  wrote:
> Hi all,
> It's a good idea to look at these reports from time to time.
>
> Note that usually some of the defects reported by static analysis are "false
> positives"; they may actually work as intended in the code due to the way a
> particular part of code behaves at run-time.
>
Coverity has some facilities to deal with false positives.

For instance, it is possible to classify an identified issue as "false
positive" or "intentional", meaning that Coverity shall ignore it in
future code scans. But more usefully we can specify a Modeling File:

"Static code analysis has some limitations in its ability to
understand certain dynamic operations. This limitation may result in
falsely detecting defects. Since most false-positive defects are
caused by few functions in your code base, Coverity allows you to tell
the analysis engine to treat these functions differently. This is
called a Modeling File. By providing a modeling file, most projects
reduce their false-positive rate to the ballpark of 10%."

Cheers,
Liviu


> Sometimes it's possible to rewrite the code slightly to eliminate false
> positives; in many cases, slightly changing the code may also make it easier
> for humans to understand, not just for Coverity.
>
> As we've found various memory corruption bugs only by testing, it's
> definitely a good idea to ensure that the warnings are fixed over time.
> Hopefully this will make some of the more elusive bugs we've had, a thing of
> the past.
>
>
>
> Liviu Andronic wrote:
>>
>> Dear all,
>> Following on this very old proposal, I went ahead and submitted the
>> LyX code for static analysis to Coverity:
>> https://scan.coverity.com/projects/4164
>>
>> Coverity has uncovered ~250 implementation defects in the LyX code
>> base, with 10 or so of high severity (memory corruption, resource
>> leaks, etc.) To view the defects, you need to connect with your Github
>> account (or create one with Coverity) and request 'Add me to project'
>> (which I shall then approve). Coverity provides overall metrics like
>> defect density (LyX scores a respectable 0.53), but also classifies
>> uncovered bugs by type and severity, and provides a nice UI trying to
>> explain to the devels the specifics of the bug and how to address it
>> (e.g. where it happens, why it's an issue, etc.)
>>
>> This tool is being used by heavy-hitters like LibreOffice, Linux
>> Kernel, Firefox or Python to improve the robustness of their code
>> base. I suspect that Coverity could prove invaluable when trying to
>> hunt down frustrating implementation issues like
>> http://www.lyx.org/trac/ticket/8854 or
>> http://www.lyx.org/trac/ticket/9049 .
>>
>> In any case the identified bugs are now ready for inspection by the
>> devels, so feel free to drop by!
>>
>> Regards,
>> Liviu
>>
>>
>> On Wed, Feb 24, 2010 at 6:52 PM, John McCabe-Dansted 
>> wrote:
>>>
>>> I found the errors reported by cppcheck much easier to fix than bug
>>> reports (e.g. generated by my keytest). For example:
>>>  [./development/lyxserver/server_monitor.c:173]: (error) Memory
>>> leak: pipename
>>> This had the obvious solution of adding free(pipename) to line 173.
>>> Convincing myself that this fix was correct wasn't quite so trivial,
>>> but still much easier than tracing down the cause of a traditional bug
>>> report.
>>>
>>> Unfortunately the cppcheck didn't seem very powerful and only found
>>> bugs in code that was virtually unused.
>>>
>>> My understanding is that Coverity is not only a much more powerful
>>> check, but also focuses on making their bug reports easy to understand
>>> and free of false-positives [1]. As such it seems that fixing many of
>>> the bugs reported by Coverity would be trivial, and may even save time
>>> as fixing dangerous code may close some of the hard to track down bugs
>>> sitting in trac.
>>>
>>> If we were to request that Coverity scan LyX would anyone either be
>>> interested in either looking through the bugs, or having someone else
>>> such as myself look through the bug reports? I understand that those
>>> who wish to see the bug reports have to agree to a click through
>>> license agreeing that if you produce a competing product to Coverity
>>> you won't use any "IP" you learnt about Coverity from looking their
>>> bug reports.
>>>
>>> --
>>> John C. McCabe-Dansted
>>> [1]
>>> http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext
>>
>>
>>
>>
>
> --
> Regards,
> Cyrille Artho - http://artho.com/
> Those who will not reason, are bigots, those who cannot,
> are fools, and those who dare not, are slaves.
> -- George Gordon Noel Byron



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: bug milestones

[Jürgen Spitzmüller]

Am Samstag 07 Februar 2015, 13:13:43 schrieb Jean-Marc Lasgouttes:
> Le 07/02/15 10:04, Georg Baum a écrit :
> > Only set a fixed milestone (like 2.1.4 or 2.2.0) if a) somebody is
> > actively
> > working on a fix or b) the bug is so severe that it would block the
> > release
> > if it is not fixed. If a bug is important, but nobody is working on it,
> > and
> > it is no shostopper, use a milestone like 2.1.x or 2.2.x. For all other
> > bugs, do not set a milestone at all.
> 
> Yes, this makes sense to me.

I would be fine with that, too.

Jürgen

> JMarc

AW: Source Tarballs for 2.1.3

[Uwe Stöhr]

Source tarballs for 2.1.3 can be found here:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
Please prepare binaries by Monday. I'd like to do the release on Tuesday.

‎Hi Richard,

It compiles fine on Windows. I think I can provide the installers on Monday. 

Regards Uwe 

reporting a bug (Mac OSX Mavericks)

[Vadim Marmer]

It happens every other time I quit LyX

Process: lyx [31542]
Path:/Applications/LyX.app/Contents/MacOS/lyx
Identifier:  org.lyx.lyx
Version: 2.1.1 (???)
Code Type:   X86-64 (Native)
Parent Process:  launchd [180]
Responsible: lyx [31542]
User ID: 501

Date/Time:   2015-02-07 12:44:17.119 -0800
OS Version:  Mac OS X 10.9.5 (13F34)
Report Version:  11
Anonymous UUID:  D69293EA-F826-0FAA-CBF7-B45C975F83F7

Sleep/Wake UUID: F2BC8F60-282D-4C06-AE54-19D707587B9D

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0010

VM Regions Near 0x10:
--> 
__TEXT 0001-0001008dd000 [ 9076K] r-x/rwx 
SM=COW  /Applications/LyX.app/Contents/MacOS/lyx

Application Specific Information:
abort() called
*** error for object 0x10400b338: pointer being freed was not allocated
 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff985a0866 __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fff8c9b235c pthread_kill + 92
2   libsystem_c.dylib   0x7fff8af4ab1a abort + 125
3   libsystem_malloc.dylib  0x7fff8add107f free + 411
4   QtGui   0x000101382f90 cleanup_mimes() + 112
5   QtCore  0x0001010fa165 
qt_call_post_routines() + 101
6   QtGui   0x0001013299f7 
QApplication::~QApplication() + 105
7   org.lyx.lyx 0x0001002eac0e 
lyx::frontend::noAppDialog(QString const&, QString const&, QMessageBox::Icon) + 
178
8   org.lyx.lyx 0x0001002e9ba2 
lyx::frontend::Alert::doError(std::basic_string const&, 
std::basic_string 
const&, bool) + 452
9   org.lyx.lyx 0x0001002e99b3 
lyx::frontend::Alert::error(std::basic_string const&, 
std::basic_string 
const&, bool) + 101
10  org.lyx.lyx 0x0001000eca2c error_handler + 478
11  libsystem_platform.dylib0x7fff8d00f5aa _sigtramp + 26
12  libobjc.A.dylib 0x7fff91ad462a (anonymous 
namespace)::AutoreleasePoolPage::pop(void*) + 454
13  com.apple.CoreFoundation0x7fff8fe7a932 
_CFAutoreleasePoolPop + 50
14  com.apple.Foundation0x7fff8bcc054c -[NSAutoreleasePool 
release] + 140
15  org.lyx.lyx 0x0001004ec0db 
closeAllLinkBackLinks + 59
16  org.lyx.lyx 0x0001002f28c2 
lyx::frontend::GuiApplication::~GuiApplication() + 36
17  org.lyx.lyx 0x0001000edc61 
lyx::LyX::prepareExit() + 1133
18  org.lyx.lyx 0x0001000f0da0 lyx::LyX::exec(int&, 
char**) + 1626
19  org.lyx.lyx 0x00011f82 main + 70
20  org.lyx.lyx 0x00011f34 start + 52

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib  0x7fff985a1662 kevent64 + 10
1   libdispatch.dylib   0x7fff94148421 _dispatch_mgr_invoke 
+ 239
2   libdispatch.dylib   0x7fff94148136 _dispatch_mgr_thread 
+ 52

Thread 2:: com.apple.CFSocket.private
0   libsystem_kernel.dylib  0x7fff985a09aa __select + 10
1   com.apple.CoreFoundation0x7fff8fefea03 __CFSocketManager + 
867
2   libsystem_pthread.dylib 0x7fff8c9b1899 _pthread_body + 138
3   libsystem_pthread.dylib 0x7fff8c9b172a _pthread_start + 137
4   libsystem_pthread.dylib 0x7fff8c9b5fc9 thread_start + 13

Thread 3:
0   libsystem_kernel.dylib  0x7fff9859ca1a mach_msg_trap + 10
1   libsystem_kernel.dylib  0x7fff9859bd18 mach_msg + 64
2   com.apple.CoreFoundation0x7fff8feb2f15 
__CFRunLoopServiceMachPort + 181
3   com.apple.CoreFoundation0x7fff8feb2539 __CFRunLoopRun + 1161
4   com.apple.CoreFoundation0x7fff8feb1e75 CFRunLoopRunSpecific 
+ 309
5   com.apple.AppKit0x7fff9229505e _NSEventThread + 144
6   libsystem_pthread.dylib 0x7fff8c9b1899 _pthread_body + 138
7   libsystem_pthread.dylib 0x7fff8c9b172a _pthread_start + 137
8   libsystem_pthread.dylib 0x7fff8c9b5fc9 thread_start + 13

Thread 4:: QProcessManager
0   libsystem_kernel.dylib  0x7fff985a09aa __select + 10
1   QtCore  0x0001010d802e 
QProcessManager::run() + 218
2   QtCore  0x000101021d0a 
QThreadPrivate::start(void*) + 490
3   libsystem_pthread.dylib 

Re: AW: Source Tarballs for 2.1.3

[Richard Heck]

On 02/07/2015 12:24 PM, Uwe Stöhr wrote:

Source tarballs for 2.1.3 can be found here:
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
Please prepare binaries by Monday. I'd like to do the release on Tuesday.

‎Hi Richard,

It compiles fine on Windows. I think I can provide the installers on Monday.


OK. Please note that the date was wrong in the original tarball: 2014 
instead of 2015. I uploaded a new one earlier today.


Richard

Re: Yet more static analysis: Use Coverity?

[Jean-Marc Lasgouttes]

Le 07/02/15 03:41, Liviu Andronic a écrit :

Dear all,
Following on this very old proposal, I went ahead and submitted the
LyX code for static analysis to Coverity:
https://scan.coverity.com/projects/4164

Coverity has uncovered ~250 implementation defects in the LyX code
base, with 10 or so of high severity (memory corruption, resource
leaks, etc.) To view the defects, you need to connect with your Github
account (or create one with Coverity) and request 'Add me to project'
(which I shall then approve). Coverity provides overall metrics like
defect density (LyX scores a respectable 0.53), but also classifies
uncovered bugs by type and severity, and provides a nice UI trying to
explain to the devels the specifics of the bug and how to address it
(e.g. where it happens, why it's an issue, etc.)


That is really a great idea. Lots of things to fix, yum!

JMarc

Re: Yet more static analysis: Use Coverity?

[Liviu Andronic]

On Sat, Feb 7, 2015 at 10:31 PM, Jean-Marc Lasgouttes
 wrote:
> Le 07/02/15 03:41, Liviu Andronic a écrit :
>>
>> Dear all,
>> Following on this very old proposal, I went ahead and submitted the
>> LyX code for static analysis to Coverity:
>> https://scan.coverity.com/projects/4164
>>
>> Coverity has uncovered ~250 implementation defects in the LyX code
>> base, with 10 or so of high severity (memory corruption, resource
>> leaks, etc.) To view the defects, you need to connect with your Github
>> account (or create one with Coverity) and request 'Add me to project'
>> (which I shall then approve). Coverity provides overall metrics like
>> defect density (LyX scores a respectable 0.53), but also classifies
>> uncovered bugs by type and severity, and provides a nice UI trying to
>> explain to the devels the specifics of the bug and how to address it
>> (e.g. where it happens, why it's an issue, etc.)
>
>
> That is really a great idea. Lots of things to fix, yum!
>
Yay! Glad you all like it! :)

I propose that whenever someone finds some item particularly yummy,
and they start looking more closely into the issue, that they
nominally assign themselves to that item so that others would know
that someone is already working on it. (OK, that was unnecessarily
verbose, even if surprisingly precise, but I hope it's excusable given
that it's quite late here...)

Cheers,
Liviu


> JMarc
>



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

View/compile reduced size PDF within LyX

[James]

Is there any reason that an option within LyX to view or compile a reduced
size PDF?

For example, writing a graphic heavy document such as a thesis, which
includes large numbers of HQ photos, bitmaps, vector graphics that have
embedded raster images, can result in very large PDF files.

The PDF is no doubt the the most frequently used output, but when the files
are large they re hugely inconvenient to handle and distribute. Large PDFs
are not handled well by all machines and and can make use of them
difficult. This is especially the case when the PDF is going to be marked
up using a PDF editor and extra notes, comments and editorial additional
are added.

To reduce the PDF to a sensible size for markup, I use ghostscript at the
command line to reduce the PDF to a size suitable for markup
distribution (initially
learnt from
http://tex.stackexchange.com/questions/14429/pdftex-reduce-pdf-size-reduce-image-quality
). However, not everyone who uses LyX is comfortable using shell commands.
It would seem to be an unnecessary step to have to do this externally when
ghostscript is already required as part of the LyX installation to create
postscript files.

It would be great to see a button or Document menu item that gave an option
to view/compile in a reduced size by with ghostscript and setting the
-dPDFSETTINGS
 switch to one of the following
/screen (72dpi), /ebook (150dpi), /printer (300dpi), /prepress (300dpi),
/default.

Full command:
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook
-dNOPAUSE -dQUIET -dBATCH -sOutputFile=small.pdf big.pdf

 How hard is this to implement? Is there a reason why such
an option doesn't already exist?

Cheers
James