unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* A Pango attribute deallocated twice
@ 2018-06-05 12:29 Tommi Höynälänmaa
  2018-06-05 20:28 ` Mark H Weaver
  0 siblings, 1 reply; 6+ messages in thread
From: Tommi Höynälänmaa @ 2018-06-05 12:29 UTC (permalink / raw)
  To: guile-devel

Hi

A Pango attribute gets deallocated twice in program calc-9.scm causing
the program to crash. The Scheme code calc-9.scm is generated from the
Theme-D program calc-9.thp.

Gdb gives the following output:
---cut here---
scheme@(guile-user)> (load "rtp.scm")
scheme@(guile-user)> (__main (list "" "calc-9.go"))
*1*
*2*
(guile:1851): Pango-DEBUG: 20:41:22.941: pango_attr_color_new: 
0x555556590d60
(guile:1851): Pango-DEBUG: 20:41:22.941: klass: 0x7fffeb7c5fa0
*4*
(guile:1851): Pango-DEBUG: 20:41:23.051: pango_attr_int_new: 0x55555615ae60
(guile:1851): Pango-DEBUG: 20:41:23.051: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.051: pango_attr_list_unref ENTER
(guile:1851): Pango-DEBUG: 20:41:23.051: pango_attr_list_unref EXIT
(guile:1851): Pango-DEBUG: 20:41:23.051: pango_attr_int_new: 0x55555615afa0
(guile:1851): Pango-DEBUG: 20:41:23.051: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.051: pango_attr_int_new: 0x55555615b0c0
(guile:1851): Pango-DEBUG: 20:41:23.051: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref ENTER
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/1
(guile:1851): Pango-DEBUG: 20:41:23.063: attr: 0x55555615afa0
(guile:1851): Pango-DEBUG: 20:41:23.063: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: destroy: 0x7fffeb590dc0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/2
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/3
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/4
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref EXIT
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attribute_destroy ENTER: 
0x55555615b0c0
(guile:1851): Pango-DEBUG: 20:41:23.063: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: destroy: 0x7fffeb590dc0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attribute_destroy EXIT
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_int_new: 0x55555615aec0
(guile:1851): Pango-DEBUG: 20:41:23.063: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_int_new: 0x55555615af60
(guile:1851): Pango-DEBUG: 20:41:23.063: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref ENTER
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/1
(guile:1851): Pango-DEBUG: 20:41:23.063: attr: 0x55555615aec0
(guile:1851): Pango-DEBUG: 20:41:23.063: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: destroy: 0x7fffeb590dc0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/2
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/3
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/4
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref EXIT
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attribute_destroy ENTER: 
0x55555615af60
(guile:1851): Pango-DEBUG: 20:41:23.063: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: destroy: 0x7fffeb590dc0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attribute_destroy EXIT
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref ENTER
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/1
(guile:1851): Pango-DEBUG: 20:41:23.063: attr: 0x55555615ae60
(guile:1851): Pango-DEBUG: 20:41:23.063: klass: 0x7fffeb7c5de0
(guile:1851): Pango-DEBUG: 20:41:23.063: destroy: 0x7fffeb590dc0
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/2
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/3
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref/4
(guile:1851): Pango-DEBUG: 20:41:23.063: pango_attr_list_unref EXIT
*5*
*6*
*7*
outer lambda enter
inner lambda enter
make-button-row ENTER
make-button-row EXIT
inner lambda exit
outer lambda exit
outer lambda enter
inner lambda enter
make-button-row ENTER
make-button-row EXIT
inner lambda exit
inner lambda enter
make-button-row ENTER
make-button-row EXIT
inner lambda exit
(guile:1851): Pango-DEBUG: 20:41:23.105: pango_attr_list_unref ENTER
(guile:1851): Pango-DEBUG: 20:41:23.105: pango_attr_list_unref/1
(guile:1851): Pango-DEBUG: 20:41:23.105: attr: 0x555556590d60
(guile:1851): Pango-DEBUG: 20:41:23.105: klass: 0x7fffeb7c5fa0
(guile:1851): Pango-DEBUG: 20:41:23.105: destroy: 0x7fffeb590db0
(guile:1851): Pango-DEBUG: 20:41:23.105: pango_attr_list_unref/2
(guile:1851): Pango-DEBUG: 20:41:23.105: pango_attr_list_unref/3
(guile:1851): Pango-DEBUG: 20:41:23.105: pango_attr_list_unref/4
(guile:1851): Pango-DEBUG: 20:41:23.105: pango_attr_list_unref EXIT
(guile:1851): Pango-DEBUG: 20:41:23.105: pango_attribute_destroy ENTER: 
0x555556590d60
(guile:1851): Pango-DEBUG: 20:41:23.105: klass: 0x7fffec0014e0
(guile:1851): Pango-DEBUG: 20:41:23.105: destroy: 0x80
inner lambda enter
make-button-row ENTER

Thread 5 "guile" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff3504700 (LWP 1858)]
0x0000000000000080 in ?? ()
(gdb) backtrace
#0  0x0000000000000080 in  ()
#1  0x00007fffeb591591 in pango_attribute_destroy ()
     at /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
#2  0x00007fffeb7d3259 in  ()
     at /usr/lib/guile-gnome-2/libgw-guile-gnome-pango.so.0
#3  0x00007ffff00d3f0f in  () at /usr/lib/libgwrap-guile-runtime.so.2
#4  0x00007ffff00d3fae in  () at /usr/lib/libgwrap-guile-runtime.so.2
#5  0x00007ffff724b74d in GC_invoke_finalizers ()
     at /usr/lib/x86_64-linux-gnu/libgc.so.1
#6  0x00007ffff7affe79 in scm_run_finalizers ()
     at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#7  0x00007ffff7affed5 in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#8  0x00007ffff7af0a4a in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#9  0x00007ffff7b6a30c in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#10 0x00007ffff7b74137 in scm_call_n ()
     at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#11 0x00007ffff7b62da2 in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#12 0x00007ffff7af1030 in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#13 0x00007ffff7af10c5 in scm_c_with_continuation_barrier ()
     at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#14 0x00007ffff7b619ec in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#15 0x00007ffff7252c42 in GC_call_with_stack_base ()
     at /usr/lib/x86_64-linux-gnu/libgc.so.1
#16 0x00007ffff7b61d08 in scm_with_guile ()
     at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#17 0x00007ffff78a16db in start_thread (arg=0x7ffff3504700)
     at pthread_create.c:463
#18 0x00007ffff75ca88f in clone ()
     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)
---cut here---

The attribute deallocated twice has address 0x55555658ff60. It is
allocated by function pango_attr_color_new at the start of the log.
By comparing the properties of this attribute printed after calls to
pango_attr_list_unref and pango_attribute_destroy at the end of the
log it can be seen that the contents of the attribute have got
corrupted after the first deallocation (of course, this is not an
error).

The files related to this bug can be found at

      http://www.iki.fi/tohoyn/theme-d/theme-d-gnome-bug1.tar.bz2

There is a version file pango-attributes.c containing extra debug
information in the package. If you use that you also have to set the
environment variable G_MESSAGES_DEBUG (to value "all") so that the log
messages get printed.  When I removed the Pango-related procedure
calls from the program the bug disappeared.  When I added the same
Pango operations to the original version of calc.scm in guile-gnome
the bug did not occur. IMHO the variable attrlist should not be
deallocated at all in the position where it is done now since it is
defined in the surrounding let expression.

I use guile 2.2.3 and guile-gnome 2.16.5 on Ubuntu 18.04.

Steps to reproduce the bug:
1. Unpack file theme-d-gnome-bug1.tar.bz2 and cd to subdirectory
theme-d-gnome-bug1.
2. Launch script init.sh.
3. Launch script launch-gdb.sh.
4. Give command run.
5. After guile starts give the following commands:
   (load "rtp.scm")
   (__main (list "" "calc-9.go"))

Does anyone have ideas how to fix this?

      - Tommi Höynälänmaa





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A Pango attribute deallocated twice
  2018-06-05 12:29 A Pango attribute deallocated twice Tommi Höynälänmaa
@ 2018-06-05 20:28 ` Mark H Weaver
  2018-06-06 13:17   ` Tommi Höynälänmaa
  2018-06-07 15:10   ` Tommi Höynälänmaa
  0 siblings, 2 replies; 6+ messages in thread
From: Mark H Weaver @ 2018-06-05 20:28 UTC (permalink / raw)
  To: Tommi Höynälänmaa; +Cc: guile-devel

Hi,

Tommi Höynälänmaa <tommi.hoynalanmaa@student.tut.fi> writes:

> A Pango attribute gets deallocated twice in program calc-9.scm causing
> the program to crash. The Scheme code calc-9.scm is generated from the
> Theme-D program calc-9.thp.

[...]

> IMHO the variable attrlist should not be deallocated at all in the
> position where it is done now since it is defined in the surrounding
> let expression.

Sorry, but your expectation here is simply not fulfilled by Guile's
compiler, nor by other modern compilers.  In this case:

  (define-simple-proc make-calculator
      (((lst-panels (:uniform-list <panel>)))
       <none>
       nonpure)
    (console-display-line "*1*")
    (force-output)
    (let* ((attrlist (pango-attr-list-create))
	   (tmp1 (begin
		   (console-display-line "*2*")
		   (force-output)
		   0))
	   (tmp3 (begin
		   (pango-attr-list-insert
		    attrlist
		    (pango-attr-background-new 65535 0 0))
		   0))

I omitted the rest of this procedure, but it turns out that the only
reference to 'attrlist' is in the initializer for 'tmp3'.  After that,
there's no guarantee that Guile will retain a reference to 'attrlist'.
It probably doesn't.

If you need to artificially keep a reference to some object alive, you
should store it in a top-level variable, or in a data structure that's
referenced by a top-level variable.  Those are never optimized away.

      Mark



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A Pango attribute deallocated twice
  2018-06-05 20:28 ` Mark H Weaver
@ 2018-06-06 13:17   ` Tommi Höynälänmaa
  2018-06-07 15:10   ` Tommi Höynälänmaa
  1 sibling, 0 replies; 6+ messages in thread
From: Tommi Höynälänmaa @ 2018-06-06 13:17 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guile-devel



Mark H Weaver kirjoitti 05.06.2018 klo 23:28:
> Hi,
> Sorry, but your expectation here is simply not fulfilled by Guile's
> compiler, nor by other modern compilers.  In this case:
>
>    (define-simple-proc make-calculator
>        (((lst-panels (:uniform-list <panel>)))
>         <none>
>         nonpure)
>      (console-display-line "*1*")
>      (force-output)
>      (let* ((attrlist (pango-attr-list-create))
> 	   (tmp1 (begin
> 		   (console-display-line "*2*")
> 		   (force-output)
> 		   0))
> 	   (tmp3 (begin
> 		   (pango-attr-list-insert
> 		    attrlist
> 		    (pango-attr-background-new 65535 0 0))
> 		   0))
>
> I omitted the rest of this procedure, but it turns out that the only
> reference to 'attrlist' is in the initializer for 'tmp3'.  After that,
> there's no guarantee that Guile will retain a reference to 'attrlist'.
> It probably doesn't.
>
> If you need to artificially keep a reference to some object alive, you
> should store it in a top-level variable, or in a data structure that's
> referenced by a top-level variable.  Those are never optimized away.
>
>        Mark

Yes, but I think that the attribute still should not be deallocated twice.

      - Tommi Höynälänmaa




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A Pango attribute deallocated twice
  2018-06-05 20:28 ` Mark H Weaver
  2018-06-06 13:17   ` Tommi Höynälänmaa
@ 2018-06-07 15:10   ` Tommi Höynälänmaa
  2018-06-09  1:05     ` Mark H Weaver
  1 sibling, 1 reply; 6+ messages in thread
From: Tommi Höynälänmaa @ 2018-06-07 15:10 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guile-gtk-general, guile-devel


The reason of the bug is that the attribute argument to 
pango_attr_list_insert has been declared caller owned. I changed g-wrap 
so that WCT arguments can be callee owned and I modified guile-gnome2 so 
that the second argument of pango_attr_list_insert is declared 
callee-owned. Now it works.

Is there some reason why WCT arguments should not be callee owned? If 
not, these changes should probably be integrated in the sources.

      - Tommi Höynälänmaa




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A Pango attribute deallocated twice
  2018-06-07 15:10   ` Tommi Höynälänmaa
@ 2018-06-09  1:05     ` Mark H Weaver
  2018-06-09 15:10       ` Tommi Höynälänmaa
  0 siblings, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2018-06-09  1:05 UTC (permalink / raw)
  To: Tommi Höynälänmaa; +Cc: guile-gtk-general, guile-devel

Hi,

Tommi Höynälänmaa <tommi.hoynalanmaa@student.tut.fi> writes:
> The reason of the bug is that the attribute argument to
> pango_attr_list_insert has been declared caller owned. I changed
> g-wrap so that WCT arguments can be callee owned and I modified
> guile-gnome2 so that the second argument of pango_attr_list_insert is
> declared callee-owned. Now it works.

Thank you for your investigation, this is very helpful.

Certainly the attribute argument to 'pango_attr_list_insert' should not
be caller-owned.  However, I'm not sure that callee-owned is quite right
either, and I'm surprised that g-wrap would need to be modified to fix
this.

The Pango documentation says: "Ownership of [the attribute argument] is
assumed by the list", i.e. the first argument.  Is there a way to
arrange that?

I haven't worked with g-wrap or guile-gnome, so this is not my area of
expertise.

     Thanks,
       Mark



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: A Pango attribute deallocated twice
  2018-06-09  1:05     ` Mark H Weaver
@ 2018-06-09 15:10       ` Tommi Höynälänmaa
  0 siblings, 0 replies; 6+ messages in thread
From: Tommi Höynälänmaa @ 2018-06-09 15:10 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guile-gtk-general, guile-devel

Hi


Mark H Weaver kirjoitti 09.06.2018 klo 04:05:
> Thank you for your investigation, this is very helpful.
> Certainly the attribute argument to 'pango_attr_list_insert' should not
> be caller-owned.  However, I'm not sure that callee-owned is quite right
> either, and I'm surprised that g-wrap would need to be modified to fix
> this.
>
> The Pango documentation says: "Ownership of [the attribute argument] is
> assumed by the list", i.e. the first argument.  Is there a way to
> arrange that?
>
Property 'aggregated' might be the correct one in this case.

      - Tommi



_______________________________________________
guile-gtk-general mailing list
guile-gtk-general@gnu.org
https://lists.gnu.org/mailman/listinfo/guile-gtk-general

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-06-09 15:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-05 12:29 A Pango attribute deallocated twice Tommi Höynälänmaa
2018-06-05 20:28 ` Mark H Weaver
2018-06-06 13:17   ` Tommi Höynälänmaa
2018-06-07 15:10   ` Tommi Höynälänmaa
2018-06-09  1:05     ` Mark H Weaver
2018-06-09 15:10       ` Tommi Höynälänmaa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).