www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2021/05/28/14:48:45

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7+dev
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: "karl AT aspodata DOT se [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] errors in git gschem
In-reply-to: <alpine.DEB.2.21.2105281922160.14690@nimbus>
References: <20210527152030 DOT 03D81832CA7E AT turkos DOT aspodata DOT se> <20210528121930 DOT 617BC83B0DDA AT turkos DOT aspodata DOT se> <20210528160449 DOT 9E70083B0DDA AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 21 DOT 2105281922160 DOT 14690 AT nimbus>
Comments: In-reply-to Roland Lutz <rlutz AT hedmen DOT org>
message dated "Fri, 28 May 2021 19:49:40 +0200."
Mime-Version: 1.0
Message-Id: <20210528184745.C32D183B0DDA@turkos.aspodata.se>
Date: Fri, 28 May 2021 20:47:45 +0200 (CEST)
X-Virus-Scanned: ClamAV using ClamSMTP
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Roland:
> Ok, so I found the 'dialog->line_end != NULL' error.  The widgets in the 
...

git pull and the seg fault is gone, nice!

///////

> This bug only happens when closing the window, though.  Did the other 
> errors occur before pressing F Q or afterwards?

With no config, i.e. no ~/.gEDA (where log files seems to land) nor ~/.config/gEDA
(where geda-user.conf appear).

 Theese messagages happens before the F Q:
$ /usr/local/bin/gschem res_h.sym

(gschem:28242): libgedacairo-CRITICAL **: 20:12:29.140: file edarenderer.c: line 678 (eda_renderer_draw_pin): should not be reached

(gschem:28242): libgedacairo-CRITICAL **: 20:12:29.140: file edarenderer.c: line 678 (eda_renderer_draw_pin): should not be reached

(gschem:28242): libgedacairo-CRITICAL **: 20:12:29.140: file edarenderer.c: line 585 (eda_renderer_draw_hatch): should not be reached

(gschem:28242): libgedacairo-WARNING **: 20:12:29.140: (edacairo.c:393):eda_cairo_stroke: code should not be reached

(gschem:28242): libgedacairo-WARNING **: 20:12:29.140: (edacairo.c:401):eda_cairo_stroke: code should not be reached

(gschem:28242): libgedacairo-CRITICAL **: 20:12:29.140: eda_renderer_default_draw_cues: assertion '(object->whichend == 1) || (object->whichend == 0)' failed

(gschem:28242): libgedacairo-CRITICAL **: 20:12:29.140: eda_renderer_default_draw_cues: assertion '(object->whichend == 1) || (object->whichend == 0)' failed
$ /usr/local/bin/gschem 

(gschem:28251): libgedacairo-CRITICAL **: 20:13:14.744: file edarenderer.c: line 585 (eda_renderer_draw_hatch): should not be reached

(gschem:28251): libgedacairo-WARNING **: 20:13:14.744: (edacairo.c:401):eda_cairo_stroke: code should not be reached

(gschem:28251): libgedacairo-WARNING **: 20:13:14.744: (edacairo.c:401):eda_cairo_stroke: code should not be reached

(gschem:28251): libgedacairo-CRITICAL **: 20:13:14.744: file edarenderer.c: line 585 (eda_renderer_draw_hatch): should not be reached

(gschem:28251): libgedacairo-WARNING **: 20:13:14.744: (edacairo.c:401):eda_cairo_stroke: code should not be reached

(gschem:28251): libgedacairo-WARNING **: 20:13:14.744: (edacairo.c:401):eda_cairo_stroke: code should not be reached
$

In the first example, there are two pins, which are invisible in this
version of gschem, but you can click on them (I know where they should
be). The pins are probably related to error message 1,2,6,7.

Msg 3,4,5 are similar to msg 1,2,3/4,5,6 of the second example.

Now, theese sets of messages comes as a group when e.g. moving the
mouse pointer from outside to the inside of the gschem window and
reverse, but not if I first click in e.g. the message window.

Ditto, switching virtual displays, virtual terminal, and when
clicking inside various parts of gschem like alternativly
clicking in docks and main (canvas) window.
Could be some kind of focus/mapping thing.

//////

> I'm still tracking down the problems found by memcheck;
...

Ok, new log with current gschem at:
http://aspodata.se/tmp/valgrind_memcheck_gschem_3_log

Regards,
/Karl Hammar


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019