On 08/15/2014 11:04 PM, Andrew Zonenberg wrote:
> I filed a ticket with upstream
> http://trac.wxwidgets.org/ticket/16423#ticket so we'll see what they
> say.
>
> On Fri, 2014-08-15 at 23:53 -0400, Andrew Zonenberg wrote:
>> The invalid read seems to be a bug in wxWidgets:
>>
>> src/gtk/window.cpp
I've pretty much confirmed the crash to be an upstream bug. The stack
memory is used by other things, then passed to GDK which then dies
because the cursor is no longer pointing to useful data.
==22321== Invalid read of size 4
==22321==at 0x81F3B3C: gdk_cursor_ref (gdkcursor.c:57)
==22321==
DRC_ITEM::m_noCoordinate can be left uninitialized if the second or
third DRC_ITEM constructor is called and not followed by
SetShowNoCoordinate().
Fix attached.
--
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.ed
I filed a ticket with upstream
http://trac.wxwidgets.org/ticket/16423#ticket so we'll see what they
say.
On Fri, 2014-08-15 at 23:53 -0400, Andrew Zonenberg wrote:
> The invalid read seems to be a bug in wxWidgets:
>
> src/gtk/window.cpp:1543
>
> static void SendSetCursorEvent(wxWindowGTK* win,
The invalid read seems to be a bug in wxWidgets:
src/gtk/window.cpp:1543
static void SendSetCursorEvent(wxWindowGTK* win, int x, int y)
{
wxSetCursorEvent event(x, y);
wxWindowGTK* w = win;
do {
if (w->GTKProcessEvent(event))
{
gs_overrideCursor = &event.Ge
I'm not using codelight itself, just their precompiled wx binaries, so I
can easily remove the binary package, it was just less work than
compiling from source.
I'm investigating further now, I fixed an unrelated missing variable
initializer in the process and will be submitting a patch to that
sh
On 08/15/2014 08:32 PM, Andrew Zonenberg wrote:
> Does not crash when run under Valgrind, instead gives this error:
>
> ==32723== Invalid read of size 8
^ this error? I've seen that before and never could figure it out, nor was it
ever the
cause of any problem running valgrind.
I would say bui
Does not crash when run under Valgrind, instead gives this error:
==32723== Invalid read of size 8
==32723==at 0x5D00EC0: wxCursor::GetCursor() const (cursor.cpp:287)
==32723==by 0x5D20A8D: wxWindow::GTKUpdateCursor(bool, bool)
(window.cpp:3752)
==32723==by 0x5D002A0: UpdateCursors(wxW
Happens every time I run DRC on this board. I don't want to change the
design for fear of not being able to reproduce it.
This is with the Codelite packages of wx3.0.1 and BZR 5073 kicad on
Debian 7.
Program received signal SIGSEGV, Segmentation fault.
IA__gdk_cursor_ref (cursor=cursor@entry=0xf2
On 08/15/2014 03:18 PM, Derek Kozel wrote:
> 'eeschema' allows instances with the same name
> https://bugs.launchpad.net/kicad/+bug/593782
>
> I've just checked this bug and the faulty behaviour has already been fixed in
> the
> current revision. However there is still an incorrect behaviour whe
Understood. I actually just found an unofficial wx 3.0 package for
Debian stable, so I may end up switching over to that as well just for
crazy_imp's antialiasing fix.
On Fri, 2014-08-15 at 15:42 -0500, Dick Hollenbeck wrote:
> On 08/15/2014 02:05 PM, Andrew Zonenberg wrote:
> > As a user of wx 2.
On 08/15/2014 02:05 PM, Andrew Zonenberg wrote:
> As a user of wx 2.8 on Debian I would like to ensure that, as a minimum,
> kicad continues to build on it until the next stable Debian version
> (presumably shipping wx 3.0) is released.
You have that capability. Probably I will uninstall wx2.8 to
On 08/15/2014 02:16 PM, Wayne Stambaugh wrote:
> On 8/15/2014 3:00 PM, Dick Hollenbeck wrote:
>> On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
>>> On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
On 08/14/2014 07:31 PM, yann jautard wrote:
>
> Le 14/08/2014 16:21, Dick Hollenbeck a écrit
'eeschema' allows instances with the same name
https://bugs.launchpad.net/kicad/+bug/593782
I've just checked this bug and the faulty behaviour has already been fixed in
the current revision. However there is still an incorrect behaviour where the
symbol for the hierarchical sheet is still drawn
On 08/15/2014 10:26 AM, Барановский Константин wrote:
> I'm catched the bug where the window of the eeschema freezes.
>
> To reproduce do the next:
> 1) start kicad and opens some project (with existing schematic);
> 2) from kicad's panel start eeschema;
> 3) for some component in context menu (ri
On 8/15/2014 3:00 PM, Dick Hollenbeck wrote:
> On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
>> On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
>>> On 08/14/2014 07:31 PM, yann jautard wrote:
Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
>> I don't know if it is technically possible to
As a user of wx 2.8 on Debian I would like to ensure that, as a minimum,
kicad continues to build on it until the next stable Debian version
(presumably shipping wx 3.0) is released.
If new features can't be easily made to work on wx2.8 that's
understandable as long as there's some graceful downgr
On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
> On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
>> On 08/14/2014 07:31 PM, yann jautard wrote:
>>>
>>> Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
> I don't know if it is technically possible to change this behaviour, but
> I think it could
http://packages.ubuntu.com/trusty/libwxgtk3.0-0
for Trusty only.
With "dev" packages too.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-develope
I'm catched the bug where the window of the eeschema freezes.
To reproduce do the next:
1) start kicad and opens some project (with existing schematic);
2) from kicad's panel start eeschema;
3) for some component in context menu (right click) select "Edit
component -> Edit";
After this step ope
Hello Adam.
That's great that OSX nightly binaries are on their way.
Hi Wayne.
I'll happily take a look into the code and see what adding a check will take.
It looks like a good starter bug and I'll certainly review the coding policy.
Winbuilder is a great tool, but unfortunately still hits prob
On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
> On 08/14/2014 07:31 PM, yann jautard wrote:
>>
>> Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
I don't know if it is technically possible to change this behaviour, but
I think it could be a great improvement.
>>> :
yann
>>>
On 08/14/2014 07:31 PM, yann jautard wrote:
>
> Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
>>> I don't know if it is technically possible to change this behaviour, but
>>> I think it could be a great improvement.
>>>
>> :
>>> yann
>>>
>> Hopefully QuasiModal is not a monster.
>>
>> For signif
On 8/14/2014 6:55 PM, Derek Kozel wrote:
> Hello!
>
> First of all thank you to everyone who has contributed to getting KiCad
> to where it is now. I've made several boards with it and hope to make
> many more. I'm a recent EE/CS graduate with experience working on medium
> sized C++ projects, mos
Le 15/08/2014 02:31, yann jautard a écrit :
I updated my source tree to latest bzr to test with that revision, but
I did a mistake and I need to recompile the whole stuff. As I have
only my netbook now, it will take one hour or more, so I will test
that tomorow
Exact same thing with
25 matches
Mail list logo
