Bug#1059250: mate-screensaver: SIGSEGV of mate-screensaver while automatic activation and interfering with mouse pointer movement

[Joël Krähemann]

Package: mate-screensaver
Version: 1.26.1-1
Severity: normal

Dear Maintainer,

Screensaver was activating automatically, while darken the screen, I have 
interferred with mouse pointer. Screensaver was
not able to lock anymore the screen because it crashed with SIGSEGV.

regards, Joël


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mate-screensaver depends on:
ii  dbus-x11 1.14.10-3
ii  libc62.37-13
ii  libcairo21.18.0-1
ii  libdbus-1-3  1.14.10-3
ii  libdbus-glib-1-2 0.112-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libgl1   1.7.0-1
ii  libglib2.0-0 2.78.3-1
ii  libgtk-3-0   3.24.38-6
ii  libmate-desktop-2-17 1.26.2-1
ii  libmate-menu21.26.0-3
ii  libmatekbd4  1.26.1-1
ii  libnotify4   0.8.3-1
ii  libpam0g 1.5.2-9.1
ii  libpango-1.0-0   1.51.0+ds-3
ii  librda0  0.0.5-1.1
ii  libsystemd0  255-1
ii  libx11-6 2:1.8.7-1
ii  libxext6 2:1.3.4-1+b1
ii  libxklavier165.4-5
ii  libxss1  1:1.2.3-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  mate-desktop-common  1.26.2-1
ii  mate-screensaver-common  1.26.1-1
ii  mate-session-manager 1.26.1-2

Versions of packages mate-screensaver recommends:
ii  mate-power-manager  1.26.1-1

Versions of packages mate-screensaver suggests:
pn  rss-glx
ii  xscreensaver-data  6.06+dfsg1-3

-- no debconf information
(gdb) thread apply all bt

Thread 5 (Thread 0x7f80044cf6c0 (LWP 2033)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f8005c3da54 in g_cond_wait () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f8005bac16b in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f8005c100ca in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f8005c0fa41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f80055c43ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x7f8005644a5c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 4 (Thread 0x7f8003cce6c0 (LWP 2034)):
#0  0x7f8005637a1f in __GI___poll (fds=0x55826e608aa0, nfds=2, 
timeout=3355) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f8005be2277 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f8005be2930 in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f8005be2981 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f8005c0fa41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f80055c43ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x7f8005644a5c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7f8002c406c0 (LWP 2042)):
#0  0x7f8005637a1f in __GI___poll (fds=0x7f7fec000b90, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f8005be2277 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f8005be2930 in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f80045c54bd in  () at 
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x7f8005c0fa41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f80055c43ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x7f8005644a5c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x7f80034cd6c0 (LWP 2035)):
#0  0x7f8005637a1f in __GI___poll (fds=0x7f7ff8000b90, nfds=2, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f8005be2277 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f8005be2c1f in g_main_loop_run () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f8005df0eaa in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x7f8005c0fa41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f80055c43ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x7f8005644a5c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x7f80045d3a80 (LWP 2017)):
#0  0x7f80068873bd in g_type_check_instance () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x7f80068765fb in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x7f800687d186 in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x7f800687d243 in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x55826c9bb013 in  ()
#5  0x7f8005bdf0d9 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x7f8005be2317 in  () at 

Bug#986290: libags-audio3: wrong ref-count in ags_fx_factory.c

[Joël Krähemann]

Package: libags-audio3
Version: 3.7.44-3
Severity: normal
Tags: patch

Dear Maintainer,

Upstream discovered wrong ref-count in ags/audio/ags_fx_factory.c affecting
libags_audio.so and the gsequencer binary.

Without patching memory corruptions could occur. As AgsChannel implementation
might be finalize while in use.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/24 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libags-audio3 depends on:
ii  gstreamer1.0-plugins-bad  1.18.2-1+b1
ii  gstreamer1.0-plugins-base 1.18.3-1
ii  gstreamer1.0-plugins-good 1.18.3-1
pn  libags3   
ii  libasound21.2.4-1.1
ii  libc6 2.31-10
ii  libfftw3-double3  3.3.8-2
ii  libglib2.0-0  2.66.8-1
ii  libgstreamer-plugins-base1.0-01.18.3-1
ii  libgstreamer1.0-0 1.18.3-1
ii  libinstpatch-1.0-21.1.6-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libpulse0 14.2-2
ii  libsamplerate00.2.1+ds0-1
ii  libsndfile1   1.0.31-1
ii  libsoup2.4-1  2.72.0-2
ii  libxml2   2.9.10+dfsg-6.3+b1

libags-audio3 recommends no packages.

libags-audio3 suggests no packages.
diff --git a/ags/audio/ags_fx_factory.c b/ags/audio/ags_fx_factory.c
index 2f904c133..dd2e78fb0 100644
--- a/ags/audio/ags_fx_factory.c
+++ b/ags/audio/ags_fx_factory.c
@@ -788,10 +788,6 @@ ags_fx_factory_create_playback(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -1236,10 +1232,6 @@ ags_fx_factory_create_buffer(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -1657,6 +1649,10 @@ ags_fx_factory_create_volume(AgsAudio *audio,
 }
   }  
 
+  if(channel != NULL){
+g_object_unref(channel);
+  }
+
   if((AGS_FX_FACTORY_REMAP & (create_flags)) != 0){
 if(fx_volume_audio != NULL){
   g_object_unref(fx_volume_audio);
@@ -1683,10 +1679,6 @@ ags_fx_factory_create_volume(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -2131,10 +2123,6 @@ ags_fx_factory_create_peak(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -2589,10 +2577,6 @@ ags_fx_factory_create_eq10(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -3047,10 +3031,6 @@ ags_fx_factory_create_analyse(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -3505,10 +3485,6 @@ ags_fx_factory_create_envelope(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -3934,10 +3910,6 @@ ags_fx_factory_create_pattern(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -4381,10 +4353,6 @@ ags_fx_factory_create_notation(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -4892,10 +4860,6 @@ ags_fx_factory_create_ladspa(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -5407,10 +5371,6 @@ ags_fx_factory_create_dssi(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -6025,10 +5985,6 @@ ags_fx_factory_create_lv2(AgsAudio *audio,
   if(input != NULL){
 g_object_unref(input);
   }
-
-  if(channel != NULL){
-g_object_unref(channel);
-  }
   
   return(start_recall);
 }

Bug#985146: unblock: gsequencer/3.7.44-3

[Joël Krähemann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gsequencer

[ Reason ]
I would love to patch the user's manual chapter 2. The information
there are incomplete and were not updated as extending the UI of
gsequencer. It might cause confusion, as explaining the menus and
not cover every item or control.

Some versions of GCC complain about may-be unitialized after
return from utility functions. The provided patches fixes this.

There is a bug related to maybe-unitialized available:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983868

With hardening options the compilation fails.

[ Impact ]
If we don't patch the package might not compile anymore.

[ Tests ]
GSequencer comes with unit-tests and a functional integration
test suite. Running in debian-ci.

The source code compiles successfully.

[ Risks ]
The code is trivial.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)

unblock gsequencer/3.7.44-3
diff -Nru gsequencer-3.7.44/debian/changelog gsequencer-3.7.44/debian/changelog
--- gsequencer-3.7.44/debian/changelog  2021-02-27 19:16:33.0 +0100
+++ gsequencer-3.7.44/debian/changelog  2021-03-13 14:59:27.0 +0100
@@ -1,4 +1,21 @@
-gsequencer (3.7.44-1) UNRELEASED; urgency=medium
+gsequencer (3.7.44-3) UNRELEASED; urgency=medium
+
+  * removed rejected patches
+  * minimal patch to fix Bug#983868
+  * updated patches series file
+
+ -- Joël Krähemann   Sat, 13 Mar 2021 14:59:27 +0100
+
+gsequencer (3.7.44-2) unstable; urgency=medium
+
+  * add patch to fix undefined behavior or missing return if buffer NULL in
+utility functions
+  * add patch to fix floating point number types
+  * add patch to update chapter 2 of user manual
+
+ -- Joël Krähemann   Mon, 08 Mar 2021 18:44:04 +0100
+
+gsequencer (3.7.44-1) unstable; urgency=medium
 
   * New upstream version 3.7.44
 
diff -Nru gsequencer-3.7.44/debian/patches/patch-ags_midi_buffer_util-c.diff 
gsequencer-3.7.44/debian/patches/patch-ags_midi_buffer_util-c.diff
--- gsequencer-3.7.44/debian/patches/patch-ags_midi_buffer_util-c.diff  
1970-01-01 01:00:00.0 +0100
+++ gsequencer-3.7.44/debian/patches/patch-ags_midi_buffer_util-c.diff  
2021-03-13 14:59:27.0 +0100
@@ -0,0 +1,46 @@
+Description: fixed undefined behavior in ags_midi_buffer_util.c
+ ags_midi_buffer_util.c doesn't initialize an output variable passed
+ ags_midi_buffer_util_get_varlength(). This patch fixes the issue.
+Author: Joël Krähemann 
+Origin: upstream
+Forwarded: not-needed
+Applied-Upstream: 
http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/ags/audio/midi/ags_midi_buffer_util.c?h=3.7.x=acec022a94a5949e74a8b763730ce1ba7ec94067
+Reviewed-by: 
+Last-Update: 2021-03-13
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/ags/audio/midi/ags_midi_buffer_util.c
 b/ags/audio/midi/ags_midi_buffer_util.c
+@@ -2252,6 +2252,7 @@
+   
+   glong current_delta_time;
+   glong next_delta_time;
++  glong tmp_delta_time;
+   guint delta_time_size;
+   guchar status, prev_status;
+   guchar meta_type;
+@@ -2291,8 +2292,14 @@
+ }
+ 
+ /* read delta time */
++tmp_delta_time = 0;
++
+ delta_time_size = ags_midi_buffer_util_get_varlength(offset,
+-   _delta_time);
++   _delta_time);
++
++if(delta_time_size > 0){
++  current_delta_time = tmp_delta_time;
++}
+ 
+ /* read status byte */
+ status = offset[delta_time_size];
+@@ -2365,6 +2372,8 @@
+   offset += n;
+ 
+   /* check if status is omitted */
++  next_delta_time = 0;
++  
+   delta_time_size = ags_midi_buffer_util_get_varlength(offset,
+  _delta_time);
+   
diff -Nru gsequencer-3.7.44/debian/patches/patch-users-doc-chap2-xml.diff 
gsequencer-3.7.44/debian/patches/patch-users-doc-chap2-xml.diff
--- gsequencer-3.7.44/debian/patches/patch-users-doc-chap2-xml.diff 
1970-01-01 01:00:00.0 +0100
+++ gsequencer-3.7.44/debian/patches/patch-users-doc-chap2-xml.diff 
2021-03-13 14:59:27.0 +0100
@@ -0,0 +1,367 @@
+Description: complete missing descriptions in user's handbook
+ Some controls were not documented, this patch fixes it.
+Author: Joël Krähemann 
+Origin: upstream
+Forwarded: not-needed
+Applied-Upstream: 
http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=3.7.x=c0351c5120647668388092b343cb4b85a09eb9bd
+Reviewed-by: 
+Last-Update: 2021-03-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/docs/usersBook/chap2.xml
 b/docs/usersBook/chap2.xml
+@@ -38,16 +38,28 @@
+ 
+ 
+   
++  To remove an engine open context m

Bug#983868: gsequencer ftbfs with -Werror=maybe-uninitialized

[Joël Krähemann]

Hi all,

There is a DEP3 patch in the repository.

https://salsa.debian.org/multimedia-team/gsequencer/-/blob/master/debian/patches/patch-ags_midi_buffer_util-c.diff

My opinion is you can pass NULL to these functions but actually you
shouldn't do this.

regards,
Joël

On Wed, Mar 3, 2021 at 10:45 AM Mattia Rizzolo  wrote:
>
>
>
> On Wed, 3 Mar 2021, 10:30 am Joël Krähemann,  wrote:
>>
>> I am going to provide another tarball including this fix.
>
>
> There is no need to stage this for bullseye, it can be fixed later.
> (Also because at this point it would require a release unblock...)

Bug#983868: gsequencer ftbfs with -Werror=maybe-uninitialized

[Joël Krähemann]

Hi,

I just tested with gcc-9, the patch should fix the problems with
ags_midi_buffer_util.c.

I would call it a false positive, it is good that GCC complains but it
doesn't actually
know how a MIDI parser is implemented.

If you need a higher-level API, I recommend you:

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/midi/ags_midi_parser.h?h=3.7.x

I am going to provide another tarball including this fix.

regards,
Joël

On Wed, Mar 3, 2021 at 9:08 AM Matthias Klose  wrote:
>
> Well, that's not what the GCC developers think. The warning is there in GCC 9
> and GCC 11 as well.  The name of the option even implies that this is a 
> "maybe".
>  Forcing it to become an error with -Werror might be wrong, so if you build 
> with
> -Werrer, build with -Wno-error=maybe-uninitialized as well.
>
> On 3/2/21 3:46 PM, Joël Krähemann wrote:
> > Hi,
> >
> > This is not a GSequencer bug!
> >
> > This behavior is wanted.
> >
> > delta_time was properly initialized in ags_midi_buffer_util_seek_message().
> >
> > it would be wrong if delta_time was overridden by
> > ags_midi_buffer_util_get_varlength().
> > it does only return 0 length so varlength shall not be set.
> >
> > If you output 0 length, this means you can't use return location, so why
> > should I set it?
> >
> > regards,
> > Joël
> >
> > On Tue, Mar 2, 2021 at 1:45 PM Matthias Klose  wrote:
> >>
> >> Package: src:gsequencer
> >> Version: 3.7.38-1
> >> Severity: important
> >> Tags: sid bullseye
> >> X-Debbugs-CC: Joël Krähemann 
> >>
> >> gsequencer ftbfs with -Werror=maybe-uninitialized, with gcc-10 and gcc-11 
> >> from
> >> experimental.
> >>
> >> ags/audio/midi/ags_midi_buffer_util.c:2606:17: error: ‘current_delta_time’ 
> >> may
> >> be used uninitialized in this function [-Werror=maybe-uninitialized]
> >>  2606 | *delta_time = current_delta_time;
> >>   | ^~~~
> >> cc1: some warnings being treated as errors
> >>
> >> You don't see the error in a build log, because the libtool output is 
> >> redirected
> >> to /dev/null.
> >>
> >> Forwarded to https://gcc.gnu.org/PR99340
> >>
> >> The warning is only seen with -fPIE, not -fPIC, which is a bug in GCC.
> >>
> >> The warning itself is correct, ags_midi_buffer_util_get_varlength doesn't 
> >> always
> >> return a value in varlength.
>
diff --git a/ags/audio/midi/ags_midi_buffer_util.c b/ags/audio/midi/ags_midi_buffer_util.c
index 3121d60a0..12dae5d15 100644
--- a/ags/audio/midi/ags_midi_buffer_util.c
+++ b/ags/audio/midi/ags_midi_buffer_util.c
@@ -132,6 +132,10 @@ ags_midi_buffer_util_get_varlength(guchar *buffer,
   char c;
 
   if(buffer == NULL){
+if(varlength != NULL){
+  *varlength = 0;
+}
+
 return(0);
   }
 
@@ -192,6 +196,10 @@ ags_midi_buffer_util_get_int16(guchar *buffer,
   glong tmp;
 
   if(buffer == NULL){
+if(val != NULL){
+  *val = 0;
+}
+
 return;
   }
 
@@ -241,6 +249,10 @@ ags_midi_buffer_util_get_int24(guchar *buffer,
   glong tmp;
 
   if(buffer == NULL){
+if(val != NULL){
+  *val = 0;
+}
+
 return;
   }
   
@@ -292,6 +304,10 @@ ags_midi_buffer_util_get_int32(guchar *buffer,
   glong tmp;
 
   if(buffer == NULL){
+if(val != NULL){
+  *val = 0;
+}
+
 return;
   }
   
@@ -369,9 +385,26 @@ ags_midi_buffer_util_get_header(guchar *buffer,
 {
   static gchar header[] = "MThd";
 
-  if(g_ascii_strncasecmp(buffer,
-			 header,
-			 4)){
+  if(buffer == NULL ||
+ (!g_ascii_strncasecmp(buffer,
+			   header,
+			   4)) == FALSE){
+if(offset != NULL){
+  *offset = 0;
+}
+
+if(format != NULL){
+  *format = 0;
+}
+
+if(track_count != NULL){
+  *track_count = 0;
+}
+
+if(division != NULL){
+  *division = 0;
+}
+
 return(0);
   }
   
@@ -438,13 +471,14 @@ ags_midi_buffer_util_get_track(guchar *buffer,
 {
   static gchar track[] = "MTrk";
 
-  if(buffer == NULL){
-return(0);
-  }
-  
-  if(g_ascii_strncasecmp(buffer,
-			 track,
-			 4)){
+  if(buffer == NULL ||
+ (!g_ascii_strncasecmp(buffer,
+			   track,
+			   4)) == FALSE){
+if(offset != NULL){
+  *offset = 0;
+}
+
 return(0);
   }
 
@@ -520,6 +554,22 @@ ags_midi_buffer_util_get_key_on(guchar *buffer,
   guint delta_time_size;
   
   if(buffer == NULL){
+if(delta_time != NULL){
+  *delta_time = 0;
+}
+
+if(channel != NULL){
+  *channel = 0;
+}
+
+if(key != NULL){
+  *key = 0;
+}
+
+if(velocity != NULL){
+  *velocity = 0;
+}
+
 return(0);
   }
 

Bug#983868: gsequencer ftbfs with -Werror=maybe-uninitialized

[Joël Krähemann]

Hi,

This is not a GSequencer bug!

This behavior is wanted.

delta_time was properly initialized in ags_midi_buffer_util_seek_message().

it would be wrong if delta_time was overridden by
ags_midi_buffer_util_get_varlength().
it does only return 0 length so varlength shall not be set.

If you output 0 length, this means you can't use return location, so why
should I set it?

regards,
Joël

On Tue, Mar 2, 2021 at 1:45 PM Matthias Klose  wrote:
>
> Package: src:gsequencer
> Version: 3.7.38-1
> Severity: important
> Tags: sid bullseye
> X-Debbugs-CC: Joël Krähemann 
>
> gsequencer ftbfs with -Werror=maybe-uninitialized, with gcc-10 and gcc-11 from
> experimental.
>
> ags/audio/midi/ags_midi_buffer_util.c:2606:17: error: ‘current_delta_time’ may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
>  2606 | *delta_time = current_delta_time;
>   | ^~~~
> cc1: some warnings being treated as errors
>
> You don't see the error in a build log, because the libtool output is 
> redirected
> to /dev/null.
>
> Forwarded to https://gcc.gnu.org/PR99340
>
> The warning is only seen with -fPIE, not -fPIC, which is a bug in GCC.
>
> The warning itself is correct, ags_midi_buffer_util_get_varlength doesn't 
> always
> return a value in varlength.

Bug#973552: xserver-xorg-video-amdgpu: GPU crashed while doing screencast using ffmpeg with gsequencer

[Joël Krähemann]

Package: xserver-xorg-video-amdgpu
Version: 19.1.0-2
Severity: normal

Dear Maintainer,

While I was running ffmpeg to do a screencast showing the capabilities of
gsequencer. But while doing so the GPU crashed after some time of playback.

The system was not usable, anymore. I wasn't able to switch to TTY. Only
mouse pointer was still responsive.

I configured my display to run at a lower resolution 1920x1080x60 instead of
the available 3840x2160x30.

Here is my ffmpeg command used:

`ffmpeg -video_size 1920x1080 -framerate 30 -f x11grab -i :0.0 -c:v libx264rgb 
-crf 0 -preset ultrafast ags-screencast-001.mkv`

Here is my $HOME/.gsequencer/ags.conf:

[generic]
disable-feature=experimental
autosave-thread=false
segmentation=4/4
engine-mode=deterministic
rt-safe=false
gui-scale=1.0

[soundcard-0]
backend=alsa
capability=playback
buffer-size=1024
pcm-channels=2
format=16
samplerate=44100
device=hw:CARD=PCH,DEV=0

[recall]
auto-sense=false

[thread]
model=multi-threaded
lock-global=ags-thread
lock-parent=ags-recycling-thread
thread-pool-max-unused-threads=4
max-precision=125

I have recorded the screen using my phone:

http://xn--krhemann-1za.com/linux-gpu-corruption.mp4

Since, I have got some functional integration tests for `gsequencer`, there
was the idea about to bisect the upgrade that introduced it.

But first, I try to use an ordinary FullHD monitor and check if the problem
happens with it, too.


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev 
e7)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.6.4-rt1 (root@deb-halo) (gcc version 9.3.0 (Debian 9.3.0-10)) 
#1 SMP PREEMPT_RT Mon Apr 13 16:25:43 CEST 2020

Xorg X server log files on system:
--
-rw-r--r-- 1 joelkraehemann joelkraehemann 664012 Jan  7  2019 
/home/joelkraehemann/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 root   root10095 Jul  4  2019 
/var/log/Xorg.2.log
-rw-r--r-- 1 root   root   105218 Sep  8  2019 
/var/log/Xorg.1.log
-rw-r--r-- 1 root   root 4940 Dec 16  2019 
/var/log/Xorg.0.0.log
-rw-r--r-- 1 root   root   537795 May 21 04:17 
/var/log/Xorg.1.0.log
-rw-r--r-- 1 root   root49191 Nov  1 19:21 
/var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[66.772] 
X.Org X Server 1.20.9
X Protocol Version 11, Revision 0
[66.772] Build Operating System: Linux 4.19.0-10-amd64 x86_64 Debian
[66.772] Current Operating System: Linux deb-halo 5.6.4-rt1 #1 SMP 
PREEMPT_RT Mon Apr 13 16:25:43 CEST 2020 x86_64
[66.772] Kernel command line: BOOT_IMAGE=/vmlinuz-5.6.4-rt1 
root=/dev/mapper/deb--halo--vg-root ro threadirqs quiet
[66.772] Build Date: 24 September 2020  09:19:06AM
[66.772] xorg-server 2:1.20.9-2 (https://www.debian.org/support) 
[66.772] Current version of pixman: 0.36.0
[66.772]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[66.772] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[66.773] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov  1 18:45:24 
2020
[66.906] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[67.003] (==) No Layout section.  Using the first Screen section.
[67.003] (==) No screen section available. Using defaults.
[67.003] (**) |-->Screen "Default Screen Section" (0)
[67.003] (**) |   |-->Monitor ""
[67.021] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[67.021] (==) Automatically adding devices
[67.021] (==) Automatically enabling devices
[67.021] (==) Automatically adding GPU devices
[67.021] (==) Max clients allowed: 256, resource mask: 0x1f
[67.128] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[67.128]Entry deleted from font path.
[67.179] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[67.179] (==) ModulePath set to "/usr/lib/xorg/modules"
[67.179] (II) The server 

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

The only thing I can do is to allow the user to configure AGS_RT_PRIORITY

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/thread/ags_audio_loop.c?h=3.0.x=93bddce14d8b1bf98f30867babd9d36db1487fbf#n660

regards,
Joël

On Thu, Nov 28, 2019 at 6:21 AM westlake  wrote:
>
> It looks like I needed to do a reboot to verify the RT-bandwidth cap at
> the 50 limit for kernel.sched_rt_runtime_us in sysctl.. so "top"
> shows gsequencer at 200% (when ags is set with 'jack')
>
> 50 is about half rt period of 1 second(100), and so 200% on this
> computer means it is half the cpu bandwidth on a 4-core machine I'm
> using.. so this confirms the application is still saturating the RT
> bandwidth.
>
> 50/100 = 50%
> 200/400% = 50%
>
> If you have a 2-core system, then saturation in the output of "top"
> would be saying "100%" because the maximum cpu-bandwidth capacity is
> 200% for 2 cores.
>
> By default, the cap-protection for RT-bandwidth is set at 95.. I was
> curious to see if sysctl's setting of kernel.sched_rt_runtime_us was
> effective..
>
> I've only known the basics, and I suppose there's something verifying
> for me here as well, I'm pretty confident I've been learning about RT
> things correctly as I've been setting up ardour+jack to work effectively..
>
> maybe someone from debian team can help with the scheduling call things..
>
> unfortunately I wouldn't be able to mentor coding specifics, but I know
> it has something to do with schedule functions.
>
> good luck..
>

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

Thank you very much for your information.

As you might have noticed there is much going on related to new threading API
in GSequencer v3.0.0

And thanks to your information you pointed me to allow adjusting
realtime priorities
by configuration seems to be mandatory.

https://savannah.nongnu.org/task/index.php?15477

best regards,
Joël

On Thu, Nov 28, 2019 at 5:51 AM westlake  wrote:
>
> it will just spike back to 110% when there is even a small load because
> you're not addressing the scheduling issue.
>
> On a 4-core system, when 50% is reserved for the RT-bandwidth the
> greatest percentage for CPU% utilization becomes 200%.
>
> But it is 200% that is shared for all RT-policy tasks..
>
> basically this means 2 cores are fully saturated by that task in "cpu
> bandwidth"..
>
> it could be 2 cores each at 100% or 4 cores each having 50% utilization
> by the various threads by the application.
>
> A properly made application wouldn't saturate all available RT
> bandwidth, as that's called an out-of-control RT application...it's a
> scheduling-function coding issue...
>
> Any-time you have a run-away and in-appropriately scheduled application,
> you automatically have an improperly behaving application that can be
> used to do things it shouldn't..
>
> eg:: fork-bombing a webserver to saturate a server, ddos-attacks is
> doing what ags is doing in saturating the cpu so that no other security
> task can run..
>
> haven't coded in long time, but I'm experienced enough to understand the
> implications about process-bombing/saturation and run-away tasks..
>
> The "FIFO" you see in the pictures -- threads with this policy class are
> RT, and so is RR, as well as BATCH policy task.. so everything of these
> three all need to fit inside the same RT bandwidth.
>
> Ags incorrectly saturates the whole rt bandwidth leaving no  RT
> bandwidth for any other RT task --- such as "drivers" which run on FIFO
> threads.
>
> I wouldn't be a strong mentor on programming at this point in time...
> but basically your application is running out of control when it is
> doing this -- and there's stability as well security issue related.
>
> My gut feeling here is you should be investigating scheduling functions
> as I think it's pretty obvious because there's an error message showing
> exactly this..
>
> Come back and update this report and let me know when this gets fixed.
> -- I could wait ..
>
> thanks
>

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

This one liner patch would reduce CPU usage from 300 % to 100 %.

cheers,
Joël

On Thu, Nov 28, 2019 at 5:35 AM Joël Krähemann  wrote:
>
> Hi,
> Just checked the CPU usage again as running the AgsDrum sequencer,
> during playback the usage goes down to 80 %.
>
> I think with a small patch we can fix this behavior.
>
> regards,
> Joël
>
> On Thu, Nov 28, 2019 at 4:26 AM Joël Krähemann  wrote:
> >
> > Hi,
> > I take your complain about CPU usage serious. I intend to target it
> > in GSequencer v2.4.x
> >
> > The high CPU usage is due to AgsThreadPool providing non-blocking
> > calls to AgsTaskThread.
> >
> > But I don't see any way to provide it to buster.
> >
> > If you are interested in what is going on related to the thread API,
> > here are further informations:
> >
> > http://savannah.nongnu.org/forum/forum.php?forum_id=9601
> >
> > sorry,
> > Joël
> >
> > On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann  
> > wrote:
> > >
> > > Hi,
> > > Yes, it is true. GSequencer consumes too much power as doing no audio
> > > processing.
> > > This was targeted with next major release v3.0.0 expected available
> > > within a half year.
> > >
> > > To change this behavior, I had to refactor the threading API of
> > > GSequencer. Currently
> > > it creates many threads without running any audio processing.
> > >
> > > The thread pool is the main cause for this, which is used by 
> > > AgsTaskThread.
> > >
> > > In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. 
> > > But for
> > > now they run asynchronous exclusive and are added by a non-blocking call.
> > >
> > >
> > > On Thu, Nov 28, 2019 at 2:00 AM westlake  
> > > wrote:
> > > >
> > > > Here when I use gsequencer, (pasuspender not needed)
> > > > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
> > > >
> > > > I can run skipping the plugin-scan, I can get the graphical interface
> > > > within a second...
> > > >
> > > > dragging the window skimps as this app is not throttling it's cpu
> > > > utilization correctly..
> > > >
> > > > When using "top", the app is using 300%...
> > > >
> > > > The limits setting /etc/security/limits.conf::
> > > > (for security limits.conf, I comment-out everything in
> > > > /etc/security/limits.d/  to keep the configuration easier to read)
> > > > ""
> > > > * hard core 0
> > > > * hard nofile 1048576
> > > > * hard rtprio 95
> > > > * - memlock unlimited
> > > > * - msgqueue 65536
> > > > * - nice -19
> > > > * - nice -20
> > > > * - rttime 10
> > > > * soft core 0
> > > > * soft nofile 1048576
> > > > * soft rtprio 95
> > > > @users  -  priority 0
> > > > ""
> > > >
> > > > changed rtprio to 35, and "top"(command) still says gsequencer is using
> > > > 300% even after reboot.
> > > > "* hard rtprio 95
> > > > * soft rtprio 95"
> > > > "* hard rtprio 35
> > > > * soft rtprio 35"
> > > >
> > > >
> > > > The observation when rtprio is set at 95-> majority of threads go at
> > > > FIFO 95. [ screenshot  provided ]
> > > >
> > > > The observation when rtprio is set at 35-> all threads are set to
> > > > SCHED_OTHER and only one gets set at FIFO with priority 20.
> > > >
> > > > 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> > > > different rtprio settings.  So the rtprio gets set aggressively with 95,
> > > > but barely nothing set with 35. << buggy.
> > > >
> > > > More buggy because with both rtprio settings the cpu is still at 300%.
> > > >
> > > >   --> ags should be down at 2-5% when it is not doing any work.
> > > >
> > > > When I look at an RT-driven application such as ardour, while it runs it
> > > > does spike in cpu it immediately goes back down to 5%.
> > > >
> > > > ..also the rt-safe option in ags doesn't do anything. cpu% is still
> > > > spiked high..
> > >
> > > The RT-safe option does reduce the calls to malloc().
> > &g

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,
Just checked the CPU usage again as running the AgsDrum sequencer,
during playback the usage goes down to 80 %.

I think with a small patch we can fix this behavior.

regards,
Joël

On Thu, Nov 28, 2019 at 4:26 AM Joël Krähemann  wrote:
>
> Hi,
> I take your complain about CPU usage serious. I intend to target it
> in GSequencer v2.4.x
>
> The high CPU usage is due to AgsThreadPool providing non-blocking
> calls to AgsTaskThread.
>
> But I don't see any way to provide it to buster.
>
> If you are interested in what is going on related to the thread API,
> here are further informations:
>
> http://savannah.nongnu.org/forum/forum.php?forum_id=9601
>
> sorry,
> Joël
>
> On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann  wrote:
> >
> > Hi,
> > Yes, it is true. GSequencer consumes too much power as doing no audio
> > processing.
> > This was targeted with next major release v3.0.0 expected available
> > within a half year.
> >
> > To change this behavior, I had to refactor the threading API of
> > GSequencer. Currently
> > it creates many threads without running any audio processing.
> >
> > The thread pool is the main cause for this, which is used by AgsTaskThread.
> >
> > In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But 
> > for
> > now they run asynchronous exclusive and are added by a non-blocking call.
> >
> >
> > On Thu, Nov 28, 2019 at 2:00 AM westlake  wrote:
> > >
> > > Here when I use gsequencer, (pasuspender not needed)
> > > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
> > >
> > > I can run skipping the plugin-scan, I can get the graphical interface
> > > within a second...
> > >
> > > dragging the window skimps as this app is not throttling it's cpu
> > > utilization correctly..
> > >
> > > When using "top", the app is using 300%...
> > >
> > > The limits setting /etc/security/limits.conf::
> > > (for security limits.conf, I comment-out everything in
> > > /etc/security/limits.d/  to keep the configuration easier to read)
> > > ""
> > > * hard core 0
> > > * hard nofile 1048576
> > > * hard rtprio 95
> > > * - memlock unlimited
> > > * - msgqueue 65536
> > > * - nice -19
> > > * - nice -20
> > > * - rttime 10
> > > * soft core 0
> > > * soft nofile 1048576
> > > * soft rtprio 95
> > > @users  -  priority 0
> > > ""
> > >
> > > changed rtprio to 35, and "top"(command) still says gsequencer is using
> > > 300% even after reboot.
> > > "* hard rtprio 95
> > > * soft rtprio 95"
> > > "* hard rtprio 35
> > > * soft rtprio 35"
> > >
> > >
> > > The observation when rtprio is set at 95-> majority of threads go at
> > > FIFO 95. [ screenshot  provided ]
> > >
> > > The observation when rtprio is set at 35-> all threads are set to
> > > SCHED_OTHER and only one gets set at FIFO with priority 20.
> > >
> > > 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> > > different rtprio settings.  So the rtprio gets set aggressively with 95,
> > > but barely nothing set with 35. << buggy.
> > >
> > > More buggy because with both rtprio settings the cpu is still at 300%.
> > >
> > >   --> ags should be down at 2-5% when it is not doing any work.
> > >
> > > When I look at an RT-driven application such as ardour, while it runs it
> > > does spike in cpu it immediately goes back down to 5%.
> > >
> > > ..also the rt-safe option in ags doesn't do anything. cpu% is still
> > > spiked high..
> >
> > The RT-safe option does reduce the calls to malloc().
> >
> > >
> > > Other observation:
> > > When ags is set at alsa, the cpu% is lower but it is still very high at
> > > 110%.
> > >
> > > The threads with the alsa setting show 0.3% cpu utilization instead of
> > > 10% when ags is set to jack..   the "main" process I suppose is the one
> > > that is always going 100+% for both alsa and jack cases.
> > >
> > > quick summary::
> > > Alsa (top without -H) --> 110%
> > > Jack (top without -H) --> 300%
> > >
> > > When it says 100+%, ags is using more than 1 core..
> > >
> > > With jack, 3 cores are now bogged down..  T

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,
I take your complain about CPU usage serious. I intend to target it
in GSequencer v2.4.x

The high CPU usage is due to AgsThreadPool providing non-blocking
calls to AgsTaskThread.

But I don't see any way to provide it to buster.

If you are interested in what is going on related to the thread API,
here are further informations:

http://savannah.nongnu.org/forum/forum.php?forum_id=9601

sorry,
Joël

On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann  wrote:
>
> Hi,
> Yes, it is true. GSequencer consumes too much power as doing no audio
> processing.
> This was targeted with next major release v3.0.0 expected available
> within a half year.
>
> To change this behavior, I had to refactor the threading API of
> GSequencer. Currently
> it creates many threads without running any audio processing.
>
> The thread pool is the main cause for this, which is used by AgsTaskThread.
>
> In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But for
> now they run asynchronous exclusive and are added by a non-blocking call.
>
>
> On Thu, Nov 28, 2019 at 2:00 AM westlake  wrote:
> >
> > Here when I use gsequencer, (pasuspender not needed)
> > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
> >
> > I can run skipping the plugin-scan, I can get the graphical interface
> > within a second...
> >
> > dragging the window skimps as this app is not throttling it's cpu
> > utilization correctly..
> >
> > When using "top", the app is using 300%...
> >
> > The limits setting /etc/security/limits.conf::
> > (for security limits.conf, I comment-out everything in
> > /etc/security/limits.d/  to keep the configuration easier to read)
> > ""
> > * hard core 0
> > * hard nofile 1048576
> > * hard rtprio 95
> > * - memlock unlimited
> > * - msgqueue 65536
> > * - nice -19
> > * - nice -20
> > * - rttime 10
> > * soft core 0
> > * soft nofile 1048576
> > * soft rtprio 95
> > @users  -  priority 0
> > ""
> >
> > changed rtprio to 35, and "top"(command) still says gsequencer is using
> > 300% even after reboot.
> > "* hard rtprio 95
> > * soft rtprio 95"
> > "* hard rtprio 35
> > * soft rtprio 35"
> >
> >
> > The observation when rtprio is set at 95-> majority of threads go at
> > FIFO 95. [ screenshot  provided ]
> >
> > The observation when rtprio is set at 35-> all threads are set to
> > SCHED_OTHER and only one gets set at FIFO with priority 20.
> >
> > 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> > different rtprio settings.  So the rtprio gets set aggressively with 95,
> > but barely nothing set with 35. << buggy.
> >
> > More buggy because with both rtprio settings the cpu is still at 300%.
> >
> >   --> ags should be down at 2-5% when it is not doing any work.
> >
> > When I look at an RT-driven application such as ardour, while it runs it
> > does spike in cpu it immediately goes back down to 5%.
> >
> > ..also the rt-safe option in ags doesn't do anything. cpu% is still
> > spiked high..
>
> The RT-safe option does reduce the calls to malloc().
>
> >
> > Other observation:
> > When ags is set at alsa, the cpu% is lower but it is still very high at
> > 110%.
> >
> > The threads with the alsa setting show 0.3% cpu utilization instead of
> > 10% when ags is set to jack..   the "main" process I suppose is the one
> > that is always going 100+% for both alsa and jack cases.
> >
> > quick summary::
> > Alsa (top without -H) --> 110%
> > Jack (top without -H) --> 300%
> >
> > When it says 100+%, ags is using more than 1 core..
> >
> > With jack, 3 cores are now bogged down..  That tells me there is
> > something very wrong.
> >
> > I can now see what is happening... there's a bug because gsequencer is
> > doing no work but it polls the cpu at 100%-300%...
>
> There many threads running. Especially AgsThreadPoll creates some
> threads that might be used.
>
> >
> > The cpu% is still grabbed even when I change  kernel.sched_rt_runtime_us
> > = 95  to 50
> >
> > so there's a serious violation of scheduling policy happening here with
> > RT kernels for this software.
>
> What scheduling policy are you talking about?
>
> >
> > ..
> > I also don't know what makes you think pulseaudio is being used, here I
> > have it masked under ~/.config/systemd/user ..  Jackdbus here 

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,
Yes, it is true. GSequencer consumes too much power as doing no audio
processing.
This was targeted with next major release v3.0.0 expected available
within a half year.

To change this behavior, I had to refactor the threading API of
GSequencer. Currently
it creates many threads without running any audio processing.

The thread pool is the main cause for this, which is used by AgsTaskThread.

In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But for
now they run asynchronous exclusive and are added by a non-blocking call.


On Thu, Nov 28, 2019 at 2:00 AM westlake  wrote:
>
> Here when I use gsequencer, (pasuspender not needed)
> LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer
>
> I can run skipping the plugin-scan, I can get the graphical interface
> within a second...
>
> dragging the window skimps as this app is not throttling it's cpu
> utilization correctly..
>
> When using "top", the app is using 300%...
>
> The limits setting /etc/security/limits.conf::
> (for security limits.conf, I comment-out everything in
> /etc/security/limits.d/  to keep the configuration easier to read)
> ""
> * hard core 0
> * hard nofile 1048576
> * hard rtprio 95
> * - memlock unlimited
> * - msgqueue 65536
> * - nice -19
> * - nice -20
> * - rttime 10
> * soft core 0
> * soft nofile 1048576
> * soft rtprio 95
> @users  -  priority 0
> ""
>
> changed rtprio to 35, and "top"(command) still says gsequencer is using
> 300% even after reboot.
> "* hard rtprio 95
> * soft rtprio 95"
> "* hard rtprio 35
> * soft rtprio 35"
>
>
> The observation when rtprio is set at 95-> majority of threads go at
> FIFO 95. [ screenshot  provided ]
>
> The observation when rtprio is set at 35-> all threads are set to
> SCHED_OTHER and only one gets set at FIFO with priority 20.
>
> 'jack' for both rtprio cases in ags' settings, 1 reboot with the
> different rtprio settings.  So the rtprio gets set aggressively with 95,
> but barely nothing set with 35. << buggy.
>
> More buggy because with both rtprio settings the cpu is still at 300%.
>
>   --> ags should be down at 2-5% when it is not doing any work.
>
> When I look at an RT-driven application such as ardour, while it runs it
> does spike in cpu it immediately goes back down to 5%.
>
> ..also the rt-safe option in ags doesn't do anything. cpu% is still
> spiked high..

The RT-safe option does reduce the calls to malloc().

>
> Other observation:
> When ags is set at alsa, the cpu% is lower but it is still very high at
> 110%.
>
> The threads with the alsa setting show 0.3% cpu utilization instead of
> 10% when ags is set to jack..   the "main" process I suppose is the one
> that is always going 100+% for both alsa and jack cases.
>
> quick summary::
> Alsa (top without -H) --> 110%
> Jack (top without -H) --> 300%
>
> When it says 100+%, ags is using more than 1 core..
>
> With jack, 3 cores are now bogged down..  That tells me there is
> something very wrong.
>
> I can now see what is happening... there's a bug because gsequencer is
> doing no work but it polls the cpu at 100%-300%...

There many threads running. Especially AgsThreadPoll creates some
threads that might be used.

>
> The cpu% is still grabbed even when I change  kernel.sched_rt_runtime_us
> = 95  to 50
>
> so there's a serious violation of scheduling policy happening here with
> RT kernels for this software.

What scheduling policy are you talking about?

>
> ..
> I also don't know what makes you think pulseaudio is being used, here I
> have it masked under ~/.config/systemd/user ..  Jackdbus here is also
> not handled by the dbus-auto-activation,...
>
> ~/.local/share/dbus-1/services/org.jackaudio.service
> "
> [D-BUS Service]
> Name=org.jackaudio.service
>
> SystemdService=dbus-org.jackaudio.service
> "
>
> ~/.config/systemd/user/dbus-org.jackaudio.service -- allows the user to
> enable/disable jackdbus and whether to have it auto-start or not..  This
> is user-defined startup unit file and is what I use here to stop jack as
> needed.
>
> pulseaudio cannot be autostarted because it is masked..
>
> ls ~/.config/systemd/user/
> pulseaudio.service -> /dev/null
> pulseaudio.socket -> /dev/null
>
> things in ~/.config/systemd/user override things in /usr/lib/systemd/user/
> /usr/lib/systemd/user/pulseaudio.service
> /usr/lib/systemd/user/pulseaudio.socket
>
> there may be a "pulse" entry in "aplay -L", but its a dormant entry as
> "pgrep -fa pulseaudio" and "pacmd" do not show no pulseaudio ever gets
> loaded...
>
> For security/audit team:
> Ags-> 2 megabytes, uses 300% of the cpu cores.
> Ardour-> a 100+ megabyte application uses just 5%.
>

What makes you think memory usage has anything to do with CPU
consumption?

> This package severely ignores scheduling restrictions. --- its' the only
> RT audio application on debian that violates and ignores settings in
> both /etc/security/limits.conf and /etc/sysctl.d/ for
> kernel.sched_rt_runtime_us.

So you think I should parse these files?

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Your computer has not enough power to run these realtime priorities.

On my workstation the realtime priorities work.

It is a dual CPU system with 2x Intel Xeon hexa core and hyper threading.

regards,
Joël

On Wed, Nov 27, 2019 at 7:59 AM Joël Krähemann  wrote:
>
> Hi,
>
> This solved the problem.
>
> rm /etc/security/limits.d/audio.conf
>
> I am even to run JACK with the attached configuration.
>
> If you want to use it, make sure samplerate and buffer-size
> matches.
>
> best regards,
> Joël
>
> On Wed, Nov 27, 2019 at 7:34 AM Joël Krähemann  wrote:
> >
> > Hi,
> >
> > I was just able to reproduce "gsequencer stalls system" while
> > using realtime priorities.
> >
> > If you want to use GSequencer might be you have to revert
> > the modifications in:
> >
> > /etc/security/limits.d
> >
> > thank you for reporting the bug.
> >
> > regards,
> > Joël
> >
> > On Wed, Nov 27, 2019 at 6:11 AM Joël Krähemann  
> > wrote:
> > >
> > > Hi,
> > >
> > > Since your CPU has enough power, I think you did some insane 
> > > modifications to
> > > /etc/security/limits.conf and related. Could you provide a tarball
> > > with the contents
> > > of:
> > >
> > > /etc/security
> > >
> > > Please, share your processes attach a file with the output of:
> > >
> > > `ps aux`
> > >
> > > It would be nice if you could provide a stack-trace of the running
> > > GSequencer process:
> > >
> > > `gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p
> > > $(pidof gsequencer)`
> > >
> > > regards,
> > > Joël
> > >
> > > On Wed, Nov 27, 2019 at 5:53 AM Joël Krähemann  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Just installed linux-image-rt from bpo, and I am not able to reproduce
> > > > the behavior ...
> > > >
> > > > I am using an Intel 4 Core CPU, too.
> > > >
> > > > Please, tell me about your modifications to:
> > > >
> > > > /etc/security/limits.conf
> > > >
> > > > best regards,
> > > > Joël
> > > >
> > > > On Wed, Nov 27, 2019 at 5:28 AM Joël Krähemann  
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Please stay on topic.
> > > > >
> > > > > On Wed, Nov 27, 2019 at 1:42 AM westlake  
> > > > > wrote:
> > > > > >
> > > > > > the system here sets RT for the applications without issue,
> > > > > >
> > > > >
> > > > > Might be but its not related as told you prior.
> > > > >
> > > > > > "$ pgrep -fa jack
> > > > > > 1717 /usr/bin/jackdbus auto
> > > > > > $ chrt -a -p 1717
> > > > > > pid 1717's current scheduling policy: SCHED_OTHER
> > > > > > pid 1717's current scheduling priority: 0
> > > > > > pid 1959's current scheduling policy: SCHED_OTHER
> > > > > > pid 1959's current scheduling priority: 0
> > > > > > pid 1960's current scheduling policy: SCHED_FIFO
> > > > > > pid 1960's current scheduling priority: 25
> > > > > > pid 1961's current scheduling policy: SCHED_OTHER
> > > > > > pid 1961's current scheduling priority: 0
> > > > > > "
> > > > > >
> > > > > > "
> > > > > > $ pgrep -fa ardour-5.12
> > > > > > 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
> > > > > > $ chrt -a -p 7358
> > > > > > pid 7358's current scheduling policy: SCHED_OTHER
> > > > > > ..
> > > > > > pid 7415's current scheduling policy: SCHED_FIFO
> > > > > > pid 7415's current scheduling priority: 20
> > > > > > pid 7424's current scheduling policy: SCHED_FIFO
> > > > > > pid 7424's current scheduling priority: 71
> > > > > > "
> > > > > >
> > > > >
> > > > > And? Probably due to settings in /etc/security/limits.conf
> > > > >
> > > > > >
> > > > > > the system does not show anything pulseaudio here,
> > > > > > "$ pgrep -fa pulseaudio
> > 

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

This solved the problem.

rm /etc/security/limits.d/audio.conf

I am even to run JACK with the attached configuration.

If you want to use it, make sure samplerate and buffer-size
matches.

best regards,
Joël

On Wed, Nov 27, 2019 at 7:34 AM Joël Krähemann  wrote:
>
> Hi,
>
> I was just able to reproduce "gsequencer stalls system" while
> using realtime priorities.
>
> If you want to use GSequencer might be you have to revert
> the modifications in:
>
> /etc/security/limits.d
>
> thank you for reporting the bug.
>
> regards,
> Joël
>
> On Wed, Nov 27, 2019 at 6:11 AM Joël Krähemann  wrote:
> >
> > Hi,
> >
> > Since your CPU has enough power, I think you did some insane modifications 
> > to
> > /etc/security/limits.conf and related. Could you provide a tarball
> > with the contents
> > of:
> >
> > /etc/security
> >
> > Please, share your processes attach a file with the output of:
> >
> > `ps aux`
> >
> > It would be nice if you could provide a stack-trace of the running
> > GSequencer process:
> >
> > `gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p
> > $(pidof gsequencer)`
> >
> > regards,
> > Joël
> >
> > On Wed, Nov 27, 2019 at 5:53 AM Joël Krähemann  
> > wrote:
> > >
> > > Hi,
> > >
> > > Just installed linux-image-rt from bpo, and I am not able to reproduce
> > > the behavior ...
> > >
> > > I am using an Intel 4 Core CPU, too.
> > >
> > > Please, tell me about your modifications to:
> > >
> > > /etc/security/limits.conf
> > >
> > > best regards,
> > > Joël
> > >
> > > On Wed, Nov 27, 2019 at 5:28 AM Joël Krähemann  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Please stay on topic.
> > > >
> > > > On Wed, Nov 27, 2019 at 1:42 AM westlake  
> > > > wrote:
> > > > >
> > > > > the system here sets RT for the applications without issue,
> > > > >
> > > >
> > > > Might be but its not related as told you prior.
> > > >
> > > > > "$ pgrep -fa jack
> > > > > 1717 /usr/bin/jackdbus auto
> > > > > $ chrt -a -p 1717
> > > > > pid 1717's current scheduling policy: SCHED_OTHER
> > > > > pid 1717's current scheduling priority: 0
> > > > > pid 1959's current scheduling policy: SCHED_OTHER
> > > > > pid 1959's current scheduling priority: 0
> > > > > pid 1960's current scheduling policy: SCHED_FIFO
> > > > > pid 1960's current scheduling priority: 25
> > > > > pid 1961's current scheduling policy: SCHED_OTHER
> > > > > pid 1961's current scheduling priority: 0
> > > > > "
> > > > >
> > > > > "
> > > > > $ pgrep -fa ardour-5.12
> > > > > 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
> > > > > $ chrt -a -p 7358
> > > > > pid 7358's current scheduling policy: SCHED_OTHER
> > > > > ..
> > > > > pid 7415's current scheduling policy: SCHED_FIFO
> > > > > pid 7415's current scheduling priority: 20
> > > > > pid 7424's current scheduling policy: SCHED_FIFO
> > > > > pid 7424's current scheduling priority: 71
> > > > > "
> > > > >
> > > >
> > > > And? Probably due to settings in /etc/security/limits.conf
> > > >
> > > > >
> > > > > the system does not show anything pulseaudio here,
> > > > > "$ pgrep -fa pulseaudio
> > > > > $
> > > > > "
> > > >
> > > > If you don't tell GSequencer to use ALSA explicit DBUS may start 
> > > > pulseaudio.
> > > >
> > > > >
> > > > > I do have alsarawjack set for applications that want to connect to 
> > > > > jack,
> > > > > so here alsa is already being used in this configuration. 
> > > > > (~/.asoundrc)
> > > > >
> > > > > The ags.conf file you provided was tested with and it still causes
> > > > > failure even without jack and not configuring alsarawjack..
> > > > >
> > > > > The rtkit-daemon.service is running, and limits.conf is set as it is
> > > > > supposed to for @audio group..
> > > > &

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

I was just able to reproduce "gsequencer stalls system" while
using realtime priorities.

If you want to use GSequencer might be you have to revert
the modifications in:

/etc/security/limits.d

thank you for reporting the bug.

regards,
Joël

On Wed, Nov 27, 2019 at 6:11 AM Joël Krähemann  wrote:
>
> Hi,
>
> Since your CPU has enough power, I think you did some insane modifications to
> /etc/security/limits.conf and related. Could you provide a tarball
> with the contents
> of:
>
> /etc/security
>
> Please, share your processes attach a file with the output of:
>
> `ps aux`
>
> It would be nice if you could provide a stack-trace of the running
> GSequencer process:
>
> `gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p
> $(pidof gsequencer)`
>
> regards,
> Joël
>
> On Wed, Nov 27, 2019 at 5:53 AM Joël Krähemann  wrote:
> >
> > Hi,
> >
> > Just installed linux-image-rt from bpo, and I am not able to reproduce
> > the behavior ...
> >
> > I am using an Intel 4 Core CPU, too.
> >
> > Please, tell me about your modifications to:
> >
> > /etc/security/limits.conf
> >
> > best regards,
> > Joël
> >
> > On Wed, Nov 27, 2019 at 5:28 AM Joël Krähemann  
> > wrote:
> > >
> > > Hi,
> > >
> > > Please stay on topic.
> > >
> > > On Wed, Nov 27, 2019 at 1:42 AM westlake  
> > > wrote:
> > > >
> > > > the system here sets RT for the applications without issue,
> > > >
> > >
> > > Might be but its not related as told you prior.
> > >
> > > > "$ pgrep -fa jack
> > > > 1717 /usr/bin/jackdbus auto
> > > > $ chrt -a -p 1717
> > > > pid 1717's current scheduling policy: SCHED_OTHER
> > > > pid 1717's current scheduling priority: 0
> > > > pid 1959's current scheduling policy: SCHED_OTHER
> > > > pid 1959's current scheduling priority: 0
> > > > pid 1960's current scheduling policy: SCHED_FIFO
> > > > pid 1960's current scheduling priority: 25
> > > > pid 1961's current scheduling policy: SCHED_OTHER
> > > > pid 1961's current scheduling priority: 0
> > > > "
> > > >
> > > > "
> > > > $ pgrep -fa ardour-5.12
> > > > 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
> > > > $ chrt -a -p 7358
> > > > pid 7358's current scheduling policy: SCHED_OTHER
> > > > ..
> > > > pid 7415's current scheduling policy: SCHED_FIFO
> > > > pid 7415's current scheduling priority: 20
> > > > pid 7424's current scheduling policy: SCHED_FIFO
> > > > pid 7424's current scheduling priority: 71
> > > > "
> > > >
> > >
> > > And? Probably due to settings in /etc/security/limits.conf
> > >
> > > >
> > > > the system does not show anything pulseaudio here,
> > > > "$ pgrep -fa pulseaudio
> > > > $
> > > > "
> > >
> > > If you don't tell GSequencer to use ALSA explicit DBUS may start 
> > > pulseaudio.
> > >
> > > >
> > > > I do have alsarawjack set for applications that want to connect to jack,
> > > > so here alsa is already being used in this configuration. (~/.asoundrc)
> > > >
> > > > The ags.conf file you provided was tested with and it still causes
> > > > failure even without jack and not configuring alsarawjack..
> > > >
> > > > The rtkit-daemon.service is running, and limits.conf is set as it is
> > > > supposed to for @audio group..
> > > >
> > > > The stall occurs with both a custom kernel as well as a bpo-stocked one
> > > > from debian.. both 5.2.x kernels..
> > > >
> > > > Other applications can get their requested process/threads elevated to 
> > > > RT...
> > > >
> > > > spotted on the ags website,
> > > >
> > > > "systemd-run -p CPUAccounting=false -p MemoryAccounting=false -p
> > > > TasksAccounting=false -p IOAccounting=false -p BlockIOAccounting=false
> > > > --scope gsequencer"
> > > >
> > > > would not make a difference because these would need be set specifically
> > > > for Debian(cgroups), and I suppose it is for the other mainstream
> > > > distributions as well.
> > > >
> > > > ags was tried with

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

Since your CPU has enough power, I think you did some insane modifications to
/etc/security/limits.conf and related. Could you provide a tarball
with the contents
of:

/etc/security

Please, share your processes attach a file with the output of:

`ps aux`

It would be nice if you could provide a stack-trace of the running
GSequencer process:

`gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p
$(pidof gsequencer)`

regards,
Joël

On Wed, Nov 27, 2019 at 5:53 AM Joël Krähemann  wrote:
>
> Hi,
>
> Just installed linux-image-rt from bpo, and I am not able to reproduce
> the behavior ...
>
> I am using an Intel 4 Core CPU, too.
>
> Please, tell me about your modifications to:
>
> /etc/security/limits.conf
>
> best regards,
> Joël
>
> On Wed, Nov 27, 2019 at 5:28 AM Joël Krähemann  wrote:
> >
> > Hi,
> >
> > Please stay on topic.
> >
> > On Wed, Nov 27, 2019 at 1:42 AM westlake  wrote:
> > >
> > > the system here sets RT for the applications without issue,
> > >
> >
> > Might be but its not related as told you prior.
> >
> > > "$ pgrep -fa jack
> > > 1717 /usr/bin/jackdbus auto
> > > $ chrt -a -p 1717
> > > pid 1717's current scheduling policy: SCHED_OTHER
> > > pid 1717's current scheduling priority: 0
> > > pid 1959's current scheduling policy: SCHED_OTHER
> > > pid 1959's current scheduling priority: 0
> > > pid 1960's current scheduling policy: SCHED_FIFO
> > > pid 1960's current scheduling priority: 25
> > > pid 1961's current scheduling policy: SCHED_OTHER
> > > pid 1961's current scheduling priority: 0
> > > "
> > >
> > > "
> > > $ pgrep -fa ardour-5.12
> > > 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
> > > $ chrt -a -p 7358
> > > pid 7358's current scheduling policy: SCHED_OTHER
> > > ..
> > > pid 7415's current scheduling policy: SCHED_FIFO
> > > pid 7415's current scheduling priority: 20
> > > pid 7424's current scheduling policy: SCHED_FIFO
> > > pid 7424's current scheduling priority: 71
> > > "
> > >
> >
> > And? Probably due to settings in /etc/security/limits.conf
> >
> > >
> > > the system does not show anything pulseaudio here,
> > > "$ pgrep -fa pulseaudio
> > > $
> > > "
> >
> > If you don't tell GSequencer to use ALSA explicit DBUS may start pulseaudio.
> >
> > >
> > > I do have alsarawjack set for applications that want to connect to jack,
> > > so here alsa is already being used in this configuration. (~/.asoundrc)
> > >
> > > The ags.conf file you provided was tested with and it still causes
> > > failure even without jack and not configuring alsarawjack..
> > >
> > > The rtkit-daemon.service is running, and limits.conf is set as it is
> > > supposed to for @audio group..
> > >
> > > The stall occurs with both a custom kernel as well as a bpo-stocked one
> > > from debian.. both 5.2.x kernels..
> > >
> > > Other applications can get their requested process/threads elevated to 
> > > RT...
> > >
> > > spotted on the ags website,
> > >
> > > "systemd-run -p CPUAccounting=false -p MemoryAccounting=false -p
> > > TasksAccounting=false -p IOAccounting=false -p BlockIOAccounting=false
> > > --scope gsequencer"
> > >
> > > would not make a difference because these would need be set specifically
> > > for Debian(cgroups), and I suppose it is for the other mainstream
> > > distributions as well.
> > >
> > > ags was tried with various audio settings, different kernels- same error
> > > message. the bug must be in ags because all other RT applications here
> > > can be set with rt priority.
> >
> > It is NOT AN ERROR.
> >
> > >
> > > recap:: The stall occurs with both a custom kernel as well as a
> > > bpo-stocked one from debian.. both 5.2.x kernels. The CPU is plenty
> > > resourceful with 4-core "Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz" with
> > > 8 gigs ram. The ags software has caused more than 12 stalls. --
> > > filesystem checks and other extra things were tried to see if it can
> > > load past the plugin-loading stage.
> > >
> >
> > Well I am going to look at the BPO kernel.
> >
> > Do you have linuxsampler installed? If so try to blacklist its LV2 plugin.
> >
> > Try to start GSequencer like following and make sure the
> > the file $HOME/.gsequencer/ags.conf is provided as prior told:
> >
> > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" pasuspender -- gsequencer
> >
> > And tell me if it stalls?
> >
> > > If someone knows how to fix this, feel free to give it a look.
> > >
> >
> > cheers, Joël

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

Just installed linux-image-rt from bpo, and I am not able to reproduce
the behavior ...

I am using an Intel 4 Core CPU, too.

Please, tell me about your modifications to:

/etc/security/limits.conf

best regards,
Joël

On Wed, Nov 27, 2019 at 5:28 AM Joël Krähemann  wrote:
>
> Hi,
>
> Please stay on topic.
>
> On Wed, Nov 27, 2019 at 1:42 AM westlake  wrote:
> >
> > the system here sets RT for the applications without issue,
> >
>
> Might be but its not related as told you prior.
>
> > "$ pgrep -fa jack
> > 1717 /usr/bin/jackdbus auto
> > $ chrt -a -p 1717
> > pid 1717's current scheduling policy: SCHED_OTHER
> > pid 1717's current scheduling priority: 0
> > pid 1959's current scheduling policy: SCHED_OTHER
> > pid 1959's current scheduling priority: 0
> > pid 1960's current scheduling policy: SCHED_FIFO
> > pid 1960's current scheduling priority: 25
> > pid 1961's current scheduling policy: SCHED_OTHER
> > pid 1961's current scheduling priority: 0
> > "
> >
> > "
> > $ pgrep -fa ardour-5.12
> > 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
> > $ chrt -a -p 7358
> > pid 7358's current scheduling policy: SCHED_OTHER
> > ..
> > pid 7415's current scheduling policy: SCHED_FIFO
> > pid 7415's current scheduling priority: 20
> > pid 7424's current scheduling policy: SCHED_FIFO
> > pid 7424's current scheduling priority: 71
> > "
> >
>
> And? Probably due to settings in /etc/security/limits.conf
>
> >
> > the system does not show anything pulseaudio here,
> > "$ pgrep -fa pulseaudio
> > $
> > "
>
> If you don't tell GSequencer to use ALSA explicit DBUS may start pulseaudio.
>
> >
> > I do have alsarawjack set for applications that want to connect to jack,
> > so here alsa is already being used in this configuration. (~/.asoundrc)
> >
> > The ags.conf file you provided was tested with and it still causes
> > failure even without jack and not configuring alsarawjack..
> >
> > The rtkit-daemon.service is running, and limits.conf is set as it is
> > supposed to for @audio group..
> >
> > The stall occurs with both a custom kernel as well as a bpo-stocked one
> > from debian.. both 5.2.x kernels..
> >
> > Other applications can get their requested process/threads elevated to RT...
> >
> > spotted on the ags website,
> >
> > "systemd-run -p CPUAccounting=false -p MemoryAccounting=false -p
> > TasksAccounting=false -p IOAccounting=false -p BlockIOAccounting=false
> > --scope gsequencer"
> >
> > would not make a difference because these would need be set specifically
> > for Debian(cgroups), and I suppose it is for the other mainstream
> > distributions as well.
> >
> > ags was tried with various audio settings, different kernels- same error
> > message. the bug must be in ags because all other RT applications here
> > can be set with rt priority.
>
> It is NOT AN ERROR.
>
> >
> > recap:: The stall occurs with both a custom kernel as well as a
> > bpo-stocked one from debian.. both 5.2.x kernels. The CPU is plenty
> > resourceful with 4-core "Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz" with
> > 8 gigs ram. The ags software has caused more than 12 stalls. --
> > filesystem checks and other extra things were tried to see if it can
> > load past the plugin-loading stage.
> >
>
> Well I am going to look at the BPO kernel.
>
> Do you have linuxsampler installed? If so try to blacklist its LV2 plugin.
>
> Try to start GSequencer like following and make sure the
> the file $HOME/.gsequencer/ags.conf is provided as prior told:
>
> LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" pasuspender -- gsequencer
>
> And tell me if it stalls?
>
> > If someone knows how to fix this, feel free to give it a look.
> >
>
> cheers, Joël

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

Please stay on topic.

On Wed, Nov 27, 2019 at 1:42 AM westlake  wrote:
>
> the system here sets RT for the applications without issue,
>

Might be but its not related as told you prior.

> "$ pgrep -fa jack
> 1717 /usr/bin/jackdbus auto
> $ chrt -a -p 1717
> pid 1717's current scheduling policy: SCHED_OTHER
> pid 1717's current scheduling priority: 0
> pid 1959's current scheduling policy: SCHED_OTHER
> pid 1959's current scheduling priority: 0
> pid 1960's current scheduling policy: SCHED_FIFO
> pid 1960's current scheduling priority: 25
> pid 1961's current scheduling policy: SCHED_OTHER
> pid 1961's current scheduling priority: 0
> "
>
> "
> $ pgrep -fa ardour-5.12
> 7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
> $ chrt -a -p 7358
> pid 7358's current scheduling policy: SCHED_OTHER
> ..
> pid 7415's current scheduling policy: SCHED_FIFO
> pid 7415's current scheduling priority: 20
> pid 7424's current scheduling policy: SCHED_FIFO
> pid 7424's current scheduling priority: 71
> "
>

And? Probably due to settings in /etc/security/limits.conf

>
> the system does not show anything pulseaudio here,
> "$ pgrep -fa pulseaudio
> $
> "

If you don't tell GSequencer to use ALSA explicit DBUS may start pulseaudio.

>
> I do have alsarawjack set for applications that want to connect to jack,
> so here alsa is already being used in this configuration. (~/.asoundrc)
>
> The ags.conf file you provided was tested with and it still causes
> failure even without jack and not configuring alsarawjack..
>
> The rtkit-daemon.service is running, and limits.conf is set as it is
> supposed to for @audio group..
>
> The stall occurs with both a custom kernel as well as a bpo-stocked one
> from debian.. both 5.2.x kernels..
>
> Other applications can get their requested process/threads elevated to RT...
>
> spotted on the ags website,
>
> "systemd-run -p CPUAccounting=false -p MemoryAccounting=false -p
> TasksAccounting=false -p IOAccounting=false -p BlockIOAccounting=false
> --scope gsequencer"
>
> would not make a difference because these would need be set specifically
> for Debian(cgroups), and I suppose it is for the other mainstream
> distributions as well.
>
> ags was tried with various audio settings, different kernels- same error
> message. the bug must be in ags because all other RT applications here
> can be set with rt priority.

It is NOT AN ERROR.

>
> recap:: The stall occurs with both a custom kernel as well as a
> bpo-stocked one from debian.. both 5.2.x kernels. The CPU is plenty
> resourceful with 4-core "Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz" with
> 8 gigs ram. The ags software has caused more than 12 stalls. --
> filesystem checks and other extra things were tried to see if it can
> load past the plugin-loading stage.
>

Well I am going to look at the BPO kernel.

Do you have linuxsampler installed? If so try to blacklist its LV2 plugin.

Try to start GSequencer like following and make sure the
the file $HOME/.gsequencer/ags.conf is provided as prior told:

LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" pasuspender -- gsequencer

And tell me if it stalls?

> If someone knows how to fix this, feel free to give it a look.
>

cheers, Joël

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

I think there is no problem except the lack CPU resources,
GSequencer needs power and pulseaudio behaves
really bad on low CPU power.

Please, try the ALSA configuration as previously been told.

This always appears, even as loading builtin config:

/home/user/.gsequencer/ags.conf

This is not bad, just an information that gsequencer was
not able to set RT priorities:

sched_setscheduler failed: Operation not permitted

to set RT priorities a process needs the permission
to do so.

regards,
Joël

On Sun, Nov 24, 2019 at 8:55 PM westlake  wrote:
>
> ""** Message: 13:46:42.039: loading preferences for:
> /home/user/.gsequencer/ags.conf
> sched_setscheduler failed: Operation not permitted
> "
>
> I managed to get the full error message before gsequencer fully stalls
> the system..
>
> "timeout -s kill -k 30 30 gsequencer"[enter]
>
> something is wrong because the "timeout" command is not able to
> auto-shutdown the gsequencer process..

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Few days ago, someone reported a similar behavior, we figured out that
low CPU power and the use of pulseaudio caused problems.

Does it help if you put a different configuration in your:

$HOME/.gsequencer/ags.conf

As shown here:

http://nongnu.org/gsequencer/help.html

Or see attachment.

regards,
Joël


On Sun, Nov 24, 2019 at 9:44 AM westlake  wrote:
>
> I tested with bpo kernel 5.2.0-0.bpo.3-rt-amd64 and similar issue.
>
> I notice there's a set_schedul* something message along with "operation
> not permitted"... that might provide a hint..
>
> there's no ~/.gsequencer directory made yet, as the stall occurs either
> while still scanning ladspa or lv2 plugins.
>
> The point of the stall is random but it occurs during the plugin-scan..
>
> -- terminal text shows the point that it stalls is random..
>
> Sometimes I am able to do Ctl-c, sometimes not and I need to do a hard
> shutdown (power button)..
>


ags.conf
Description: Binary data

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

your kernel configuration usually resides in:

/boo/config-5.2.0*

Your GSequencer configuration file resides in:

$HOME/.gsequencer/ags.conf

PLEASE, attach both files.

regards,
Joël

On Sat, Nov 16, 2019 at 4:35 AM westlake  wrote:
>
> Bugreport on "Gsequencer" Case:
>   - Kernel I've been using while using Gsequencer was a non-debian build
> that has RT support. (built on this system by me)
>
> Bugreport on Debian Kernel Backports: --- I am about to file a report.
>   - bpo Kernel has an issue:  Chrome cannot start and complains about
> not being able to run due to not being able to create a "sandbox"
>-> ( fwiw I'm filing a report on this to
> linux-image-5.2.0-0.bpo.3-rt-amd64-unsigned )
>
>
> Kernel rebooted my system and sticking with my custom boot-kernel for
> now as I can run chrome again.
>
> I did not check to see if I can run gsequencer with the bpo kernel.
>
> I am using the basic "make deb-pkg" with RT patches. gcc-8 was used to
> compile this kernel.
>
> I am using other RT applications such as ardour, and jackd2/jackdbus and
> I'm not noticing issues..
>
> cat /proc/version
> "Linux version 5.2.14-rt7 (customx@debian) (gcc version 8.3.0 (Debian
> 8.3.0-6)) #1 SMP PREEMPT RT Mon Sep 30 05:58:30 EDT 2019
> "
>
> On 2019-11-13 5:50 a.m., Joël Krähemann wrote:
> > Hi,
> >
> > thank you for reporting the bug.
> >
> > Do you use a custom realtime kernel configuration?
> >
> > best regards,
> > Joël
> >
> > On Tue, Nov 12, 2019 at 10:18 AM westlake  wrote:
> >>
> >> Package: gsequencer
> >> Version: 2.1.53-2
> >> Severity: important
> >>
> >> stalls a system that is running on an RT kernel
> >>
> >
>

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

Don't forget to provide GSequencer configuration in $HOME/.gsequencer/ags.conf

regards,
Joël

On Wed, Nov 13, 2019 at 1:25 PM Joël Krähemann  wrote:
>
> Hi,
>
> I just installed realtime kernel and gsequencer from debian repository.
>
> I am not able to reproduce.
>
> please provide more information and your kernel configuration.
>
> cheers,
> Joël
>
> On Wed, Nov 13, 2019 at 11:50 AM Joël Krähemann  wrote:
> >
> > Hi,
> >
> > thank you for reporting the bug.
> >
> > Do you use a custom realtime kernel configuration?
> >
> > best regards,
> > Joël
> >
> > On Tue, Nov 12, 2019 at 10:18 AM westlake  wrote:
> > >
> > > Package: gsequencer
> > > Version: 2.1.53-2
> > > Severity: important
> > >
> > > stalls a system that is running on an RT kernel
> > >

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

I just installed realtime kernel and gsequencer from debian repository.

I am not able to reproduce.

please provide more information and your kernel configuration.

cheers,
Joël

On Wed, Nov 13, 2019 at 11:50 AM Joël Krähemann  wrote:
>
> Hi,
>
> thank you for reporting the bug.
>
> Do you use a custom realtime kernel configuration?
>
> best regards,
> Joël
>
> On Tue, Nov 12, 2019 at 10:18 AM westlake  wrote:
> >
> > Package: gsequencer
> > Version: 2.1.53-2
> > Severity: important
> >
> > stalls a system that is running on an RT kernel
> >

Bug#944589: gsequencer: stalls system

[Joël Krähemann]

Hi,

thank you for reporting the bug.

Do you use a custom realtime kernel configuration?

best regards,
Joël

On Tue, Nov 12, 2019 at 10:18 AM westlake  wrote:
>
> Package: gsequencer
> Version: 2.1.53-2
> Severity: important
>
> stalls a system that is running on an RT kernel
>

Bug#933875: gsequencer: AgsThread synchronization broken

[Joël Krähemann]

Source: gsequencer
Severity: normal

Dear Maintainer,

GSequencer v2.2.10 introduced an experimental synchronization routine.
AgsThread was improved by later versions. The application is not usable
with current version in unstable and testing.

Please update to latest upstream.

regards,
Joël


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/24 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#928500: mentors.debian.net

[Joël Krähemann]

Hi,

FYI:

https://mentors.debian.net/package/gsequencer

cheers,
Joël

Bug#928500: some notes

[Joël Krähemann]

Hi,

Section should be sound.

 * Package name: gsequencer
   Version   : 2.1.53-2
   Upstream Author : Joël Krähemann 
 * URL   : http://nongnu.org/gsequencer
 * License  : GPLv3+
   Section   : section

Since the repository contains newer upstream packages, you probably
have to do following:

git checkout debian/2.1.53-2
git checkout master -- debian/patches/
dch -v 2.1.53-3

best regards,
Joël

Bug#928500: additional information

[Joël Krähemann]

 * Package name: gsequencer
   Version   : 2.1.53-2
   Upstream Author : Joël Krähemann 
 * URL   : http://nongnu.org/gsequencer
 * License  : GPLv3+
   Section   : optional

  It builds those binary packages:

gsequencer - the application's UI
midi2xml - a command line utility to convert SMF

I would love to do an unstable upload to buster, containing bug-fixes
of severity important:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927865

Best regards,
Joël

Bug#928500: sponsorship-requests: additional sponsor for gsequencer

[Joël Krähemann]

Package: sponsorship-requests
Severity: normal

Dear Maintainer,

Since my sponsor has not enough time to do a review for gsequencer
within next days, he gave me an advice to look for an additional sponsor.

https://salsa.debian.org/multimedia-team/gsequencer

best regards,
Joël Krähemann

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#927865: gsequencer: Important upstream bug-fixes

[Joël Krähemann]

Package: gsequencer
Version: 2.1.53-2
Severity: important

Dear Maintainer,

There are 6 patches available with severity important.

* ags-audio-threads-safe-get-type.patch
* ags-osc-manual-wrong-tag.patch
* ags_copy_pattern_channel-bank-index-as-float.patch
* ags_delay-fix-accessing-64-bit.patch
* ags_file_link-missing-set-as-open-files.patch
* ags_simple_file-missing-unset-reverse-mapping.patch

All ags_*_get_type() have to be thread-safe and race condition aware.

The OSC manual uses a wrong tag for specifying para.

There is a 64 bit issue in ags_copy_pattern_channel_run.c and
ags_play_notation_audio_run.c as accessing AgsDelay property.

Under certain circumstances AgsFileLink is not properly set
as assigning files to AgsAudio's input channels.

There is some inconsistency as reading AgsSimpleFile projects. It
causes the reverse mapping not properly restored.


I hope these patches can be provided to debian buster release via
unstable update.


by Joël Krähemann


-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gsequencer depends on:
ii  libags-audio2 2.1.53-2
ii  libags-gui2   2.1.53-2
ii  libags2   2.1.53-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-8
ii  libcairo2 1.16.0-4
ii  libfftw3-double3  3.3.8-2
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-1
ii  libgtk2.0-0   2.24.32-3
ii  libinstpatch-1.0-01.0.0-7
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libpangoft2-1.0-0 1.42.4-6
ii  libpulse-mainloop-glib0   12.2-4
ii  libpulse0 12.2-4
ii  libsndfile1   1.0.28-6
ii  libx11-6  2:1.6.7-1
ii  libxml2   2.9.4+dfsg1-7+b3

gsequencer recommends no packages.

Versions of packages gsequencer suggests:
ii  fluid-soundfont-gm  3.1-5.1
ii  fluid-soundfont-gs  3.1-5.1
ii  hydrogen0.9.7-6
ii  hydrogen-drumkits   2017.09.19~dfsg-1
pn  timgm6mb-soundfont  

-- no debconf information

Bug#923951: gsequencer: there are important upstream bug-fixes available

[Joël Krähemann]

Source: gsequencer
Version: 2.1.53
Severity: important

Dear Maintainer,

There are 3 important patches available with severity important:

* ags_thread-posix-max-precision.patch
* ags_simple_file_read_config.patch
* ags_automation_get_value.patch

The max precision and read config are related somehow to each other.
As applying new configuration the AgsThread:max-precision property
is going to be changed. The parameter specification for this is
wrong.

The read config didn't apply correct configuration causing additional
problems.

The automation patch makes the automation editor usable, without it
is useless.

Note, the fixes were available before the freeze dead-line but came
along with many other changes.

best regards,
Joël


-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/24 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

[Joël Krähemann]

Hi,

Yes, it is an application bug. So, I fixed my upstream source. Just recognized
calling pthread_cond_destroy() twice, later.

Best regards,
Joël

On Wed, Mar 6, 2019 at 11:44 AM Florian Weimer  wrote:
>
> * Joël Krähemann:
>
> > This happens as you call pthread_cond_destroy() twice on the very same
> > cond variable.
>
> Surely that's an application bug.  Why do you think this is a glibc
> issue?
>
> Thanks,
> Florian

Bug#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

[Joël Krähemann]

Hi,

This happens as you call pthread_cond_destroy() twice on the very same
cond variable.

Just attached a file to reproduce.

Bests,
Joël

On Tue, Mar 5, 2019 at 4:27 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 923802: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923802.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  GNU Libc Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 923...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 923802: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923802
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
#include 

#include 

int
main(int argc, char **argv)
{
  pthread_cond_t *cond;

  cond = (pthread_cond_t *) malloc(sizeof(pthread_cond_t));

  pthread_cond_init(cond, NULL);

  pthread_cond_destroy(cond);
  pthread_cond_destroy(cond);

  return(0);
}

Bug#923802: pthread: dead-lock while pthread_cond_destroy()

[Joël Krähemann]

Package: libc0.1-dev
Version: 2.25-2
Severity: normal
File: pthread

Dear Maintainer,

As checking why GSequencer's test didn't continue, I have discovered a dead-lock
as calling pthread_cond_destroy()

http://salsa.debian.org/multimedia-team/gsequencer

Here is the command to reproduce:

joel@kbsd:~/gsequencer-2.1.64$ libtool --mode=execute gdb 
ags_condition_manager_test 
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-kfreebsd-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/home/joel/gsequencer-2.1.64/.libs/ags_condition_manager_test...done.
(gdb) r
Starting program: /home/joel/gsequencer-2.1.64/.libs/ags_condition_manager_test 


 CUnit - A unit testing framework for C - Version 2.1-3
 http://cunit.sourceforge.net/


Suite: AgsConditionManagerTest
  Test: test of AgsConditionManager insert ...passed
  Test: test of AgsConditionManager remove ...^Z
Program received signal SIGTSTP, Stopped (user).
__syscall__umtx_op () at ../sysdeps/unix/syscall-template.S:76
76  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00080360f1da in __syscall__umtx_op () at 
../sysdeps/unix/syscall-template.S:76
#1  0x00080360d8cc in __lll_lock_wait_private (futex=0x12479a0) at 
../sysdeps/unix/bsd/bsd4.4/kfreebsd/fbtl/lowlevellock.c:31
#2  0x00080360aa9b in __pthread_cond_destroy (cond=cond@entry=0x12479a0) at 
pthread_cond_destroy.c:34
#3  0x0008018982f2 in ags_condition_manager_remove 
(condition_manager=0x12410a0, lock_object=0x12444d0)
at ags/thread/ags_condition_manager.c:176
#4  0x0102229e in ags_condition_manager_test_remove () at 
ags/test/thread/ags_condition_manager_test.c:136
#5  0x000801ab130f in  () at /usr/lib/x86_64-kfreebsd-gnu/libcunit.so.1
#6  0x000801ab154d in  () at /usr/lib/x86_64-kfreebsd-gnu/libcunit.so.1
#7  0x000801ab19be in CU_run_all_tests () at 
/usr/lib/x86_64-kfreebsd-gnu/libcunit.so.1
#8  0x01021fc0 in main (argc=, argv=) at 
ags/test/thread/ags_condition_manager_test.c:218


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 10.3-0-amd64
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc0.1-dev:kfreebsd-amd64 depends on:
ii  kfreebsd-kernel-headers  10.3~8
ii  libc-dev-bin 2.25-2
ii  libc0.1  2.25-2

libc0.1-dev:kfreebsd-amd64 recommends no packages.

Versions of packages libc0.1-dev:kfreebsd-amd64 suggests:
pn  glibc-doc 
ii  manpages-dev  4.16-1

-- no debconf information

Bug#923625: gsequencer: please update to latest version v2.1.64

[Joël Krähemann]

Source: gsequencer
Severity: wishlist

Dear Maintainer,

Please update to latest GSequencer version 2.1.64. Introduced changes
are described on debian multimedia mailing list:

https://lists.debian.org/debian-multimedia/2019/03/msg7.html

Version 2.1.64 was just merged to master then created a new branch
2.2.x of it. I as upstream expect that versioning is straight forward.

But in debian is still version 2.1.53 published. Further I wish latest
improvements and bug-fixes are included in debian.


by Joël Krähemann


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#919269: autopkgtest: provide stack-traces of crashed integration tests

[Joël Krähemann]

Package: autopkgtest
Severity: normal

Dear Maintainer,

I am the upstream of GSequencer. The software comes with system integration 
tests.

https://salsa.debian.org/multimedia-team/gsequencer/blob/master/debian/tests/ags-integration-test

The makefile compiles the integrations sets and runs them against the 
installation.

https://salsa.debian.org/multimedia-team/gsequencer/blob/master/functional-system-tests.mk.am#L144

Since they can crash and actually they do on other architectures than amd64 as 
seen here:

https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer

So I tried to reproduce the crash with my ubuntu i386 chroot but without 
success. The
integration test didn't crash and completed successfuly.

I think there is probably an issue.

It would be nice to have stack-traces for such cases. With the package 
"systemd-coredump"
you can easily retrieve stack-traces by running `coredumpctl debug`. This 
without explicitly
running in gdb.

by Joël

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.0~alpha3
ii  libdpkg-perl1.19.2
ii  procps  2:3.3.15-2
ii  python3 3.6.7-1
ii  python3-debian  0.1.33

Versions of packages autopkgtest recommends:
ii  autodep8  0.17

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
pn  ovmf  
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
pn  qemu-utils
pn  schroot   
pn  vmdb2 

Bug#909195: openshot-qt crashes during export

[Joël Krähemann]

Hi,

The media files are available here:
http://krähemann.com/reportbug/openshot-qt/

Good luck,
Joël
On Wed, Sep 19, 2018 at 4:54 PM Joël Krähemann  wrote:
>
> Package: openshot-qt
> Version: 2.4.2+dfsg1-1
> Severity: normal
>
> Dear Maintainer,
>
> Openshot-qt crashes during export. I use a screencast captured with `ffmpeg` 
> and webcam `guvcview`. Audio is provided by gsequencer-2.0.13 as signed 16 
> bit WAV PCM.
>
> Thought I can export using:
>
> https://github.com/OpenShot/openshot-qt/releases/download/daily/OpenShot-v2.4.2-dev1-1537088579-688c6b75-d0e70dd3-x86_64.AppImage
>
> But can't tell about the result because it is still exporting. I could 
> provide you the media files. I have provided a stack-trace as attachment.
>
> Best regards,
> Joël
>
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.18.0-1-amd64 (SMP w/24 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages openshot-qt depends on:
> ii  fonts-cantarell 0.111-2
> ii  libjs-jquery3.2.1-1
> ii  python3 3.6.6-1
> ii  python3-openshot0.2.0+dfsg1-1
> ii  python3-pkg-resources   40.2.0-1
> ii  python3-pyqt5   5.11.2+dfsg-1+b1
> ii  python3-pyqt5.qtsvg 5.11.2+dfsg-1+b1
> ii  python3-pyqt5.qtwebkit  5.11.2+dfsg-1+b1
> ii  python3-requests2.18.4-2
> ii  python3-zmq 17.1.0-1
>
> Versions of packages openshot-qt recommends:
> ii  blender   2.79.b+dfsg0-4
> ii  inkscape  0.92.3-3
>
> Versions of packages openshot-qt suggests:
> ii  openshot-qt-doc  2.4.2+dfsg1-1
>
> -- no debconf information

Bug#909195: openshot-qt crashes during export

[Joël Krähemann]

Package: openshot-qt
Version: 2.4.2+dfsg1-1
Severity: normal

Dear Maintainer,

Openshot-qt crashes during export. I use a screencast captured with `ffmpeg` 
and webcam `guvcview`. Audio is provided by gsequencer-2.0.13 as signed 16 bit 
WAV PCM.

Thought I can export using:

https://github.com/OpenShot/openshot-qt/releases/download/daily/OpenShot-v2.4.2-dev1-1537088579-688c6b75-d0e70dd3-x86_64.AppImage

But can't tell about the result because it is still exporting. I could provide 
you the media files. I have provided a stack-trace as attachment.

Best regards,
Joël


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-1-amd64 (SMP w/24 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openshot-qt depends on:
ii  fonts-cantarell 0.111-2
ii  libjs-jquery3.2.1-1
ii  python3 3.6.6-1
ii  python3-openshot0.2.0+dfsg1-1
ii  python3-pkg-resources   40.2.0-1
ii  python3-pyqt5   5.11.2+dfsg-1+b1
ii  python3-pyqt5.qtsvg 5.11.2+dfsg-1+b1
ii  python3-pyqt5.qtwebkit  5.11.2+dfsg-1+b1
ii  python3-requests2.18.4-2
ii  python3-zmq 17.1.0-1

Versions of packages openshot-qt recommends:
ii  blender   2.79.b+dfsg0-4
ii  inkscape  0.92.3-3

Versions of packages openshot-qt suggests:
ii  openshot-qt-doc  2.4.2+dfsg1-1

-- no debconf information
joelkraehemann@deb-halen:~$ openshot-qt 
Loaded modules from installed directory: 
/usr/lib/python3/dist-packages/openshot_qt
  launch:INFO 
  launch:INFOOpenShot (version 2.4.2)
  launch:INFO 

(python3:6418): Gtk-WARNING **: 15:46:53.577: Theme parsing error: 
gtk-widgets.css:186:14: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.577: Theme parsing error: 
gtk-widgets.css:186:14: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.582: Theme parsing error: 
gtk-widgets.css:2749:24: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.582: Theme parsing error: 
gtk-widgets.css:2749:24: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.582: Theme parsing error: 
gtk-widgets.css:2940:14: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.582: Theme parsing error: 
gtk-widgets.css:2940:14: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.582: Theme parsing error: 
gtk-widgets.css:2946:17: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.585: Theme parsing error: 
gtk-widgets.css:4083:14: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.585: Theme parsing error: 
gtk-widgets.css:4083:14: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.585: Theme parsing error: 
gtk-widgets.css:4088:17: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.586: Theme parsing error: 
gtk-widgets.css:4729:14: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.586: Theme parsing error: 
gtk-widgets.css:4729:14: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.588: Theme parsing error: 
xfce.css:47:16: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.588: Theme parsing error: 
xfce.css:47:16: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.588: Theme parsing error: 
lightdm-gtk-greeter.css:16:14: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.588: Theme parsing error: 
lightdm-gtk-greeter.css:16:14: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:26:14: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:26:14: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:40:16: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:40:16: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:96:14: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:100:16: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:100:16: Expected a string.

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing error: 
lightdm-gtk-greeter.css:279:14: not a number

(python3:6418): Gtk-WARNING **: 15:46:53.589: Theme parsing 

Bug#898322: openshot: export crashes

[Joël Krähemann]

Hi,

I added deb-multimedia.org because no video editor was working.

Bests,
Joël


On Fri, May 11, 2018 at 10:50 AM, Fabian Greffrath <fab...@debian.org> wrote:
> Joël Krähemann wrote:
>> iu  openshot-qt  1:2.4.1-dmo2
>
> Maybe this is your problem. Please replace this package with the one from
> Debian.
>
> Thanks,
>
>  - Fabian
>

Bug#898322: openshot: export crashes

[Joël Krähemann]

Package: openshot
Version: 2.4.1+dfsg1-1
Severity: normal

Dear Maintainer,

After my editing my screencast recorded using ffmpeg as MKV and audio exported
from GSequencer as WAV. I basically combined MKV and WAV. The export crashes
after writing a few MB.

I wanted to export HD video 1080p as MP4 without any success.

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-1-amd64 (SMP w/24 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openshot depends on:
iu  openshot-qt  1:2.4.1-dmo2

openshot recommends no packages.

openshot suggests no packages.

-- no debconf information

Bug#894386: libinstpatch: memory corruption in file IpatchSF2Reader.c

[Joël Krähemann]

Source: libinstpatch
Severity: normal

Dear Maintainer,

The file IpatchSF2Reader.c has seen in the upstream code base some fixes
of potential memory corruption. This can lead to undefined behaviour.

I provide a patch with the specific changes, fixing the issue.

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-2-amd64 (SMP w/24 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- libinstpatch-1.0.0/libinstpatch/IpatchSF2Reader.c   2010-10-25 
12:46:26.0 -0400
+++ libinstpatch-1.0.0.orig/libinstpatch/IpatchSF2Reader.c  2018-03-29 
11:57:52.433939326 -0400
@@ -647,13 +647,13 @@
   if (!ipatch_file_read (riff->handle, bag_table, chunk->size, err))
 return (FALSE);   /* bag_table will be freed by finalize() */
 
-  pgenndx = IPATCH_FILE_SWAP16 (riff->handle, _table[0]);
-  pmodndx = IPATCH_FILE_SWAP16 (riff->handle, _table[1]);
+  pgenndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[0]);
+  pmodndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[1]);
 
   for (i=0; i < reader->pbag_count; i++)
 {
-  genndx = IPATCH_FILE_SWAP16 (riff->handle, _table[(i+1)*2]);
-  modndx = IPATCH_FILE_SWAP16 (riff->handle, _table[(i+1)*2+1]);
+  genndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[(i+1)*2]);
+  modndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[(i+1)*2+1]);
 
   if (genndx < pgenndx)
{
@@ -973,13 +973,13 @@
   if (!ipatch_file_read (riff->handle, bag_table, chunk->size, err))
 return (FALSE);   /* bag_table will be freed by finalize() */
 
-  pgenndx = IPATCH_FILE_SWAP16 (riff->handle, _table[0]);
-  pmodndx = IPATCH_FILE_SWAP16 (riff->handle, _table[1]);
+  pgenndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[0]);
+  pmodndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[1]);
 
   for (i=0; i < reader->ibag_count; i++)
 {
-  genndx = IPATCH_FILE_SWAP16 (riff->handle, _table[(i+1)*2]);
-  modndx = IPATCH_FILE_SWAP16 (riff->handle, _table[(i+1)*2+1]);
+  genndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[(i+1)*2]);
+  modndx = IPATCH_FILE_SWAP16 (riff->handle->file, _table[(i+1)*2+1]);
 
   if (genndx < pgenndx)
{

Bug#888470: pa_glib_main_loop_new()

[Joël Krähemann]

Due to refactoring in GSequencer pa_main_loop_new() was not suitable
anymore. Moving to pa_glib_main_loop_new() actually solved the issue.

Bests,
Joël

Bug#888470: pulseaudio: make pulseaudio callback less penetrant

[Joël Krähemann]

Package: pulseaudio
Version: 11.1-4
Severity: normal
File: pulseaudio

Dear Maintainer,

pulseaudio callback is such penetrant that it brings down my desktop 
environment.
The current situation is as running GSequencer with pulseaudio on a macbook pro 
2016
it slows down the entire desktop. The mouse pointer starts to jump and no 
precise
pointing anymore possible. Keyboard input is delayed, too. The input subsystem 
went
mad.

The issue was introduced recently. Prior it worked seemless. There was some 
modifications
in pulseaudio disturbing my application and desktop environment.

During early development of GSequencer, I experienced similar problems as 
writing to
ALSA.

A software mustn't bring down the input subsystem.

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/24 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.116
ii  libasound2   1.1.3-5
ii  libasound2-plugins   1.1.1-1
ii  libc62.26-5
ii  libcap2  1:2.25-1.2
ii  libdbus-1-3  1.12.2-1
ii  libgcc1  1:7.2.0-20
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-2
ii  liborc-0.4-0 1:0.4.28-1
ii  libpulse011.1-4
ii  libsm6   2:1.2.2-1+b3
ii  libsndfile1  1.0.28-4
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   7.2.0-20
ii  libsystemd0  236-3+b1
ii  libtdb1  1.3.15-2
ii  libudev1 236-3+b1
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 9.20170808
ii  pulseaudio-utils 11.1-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.2-1
ii  libpam-systemd 236-3+b1
ii  rtkit  0.11-5

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 236-3+b1

Bug#887723: mate-screensaver: the screen stays darken and desktop not available anymore

[Joël Krähemann]

Package: mate-screensaver
Version: 1.18.2-1
Severity: serious
Justification: the desktop must be available

Dear Maintainer,

I have installed mate-desktop and its screensaver. The screen
stays darken after a while it was darken. Hitting my Logitech
USB wireless keyboard doesn't show up login screen.

Only way out is to restart lightdm:

`systemctl restart lightdm`

This possibily leads to data loss.

Best regards,
Joël

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mate-screensaver depends on:
ii  dbus-x11  1.12.2-1
ii  libatk1.0-0   2.26.1-2
ii  libc6 2.26-4
ii  libcairo-gobject2 1.15.8-3
ii  libcairo2 1.15.8-3
ii  libdbus-1-3   1.12.2-1
ii  libdbus-glib-1-2  0.108-3
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libgl11.0.0-1
ii  libglib2.0-0  2.54.3-1
ii  libgtk-3-03.22.26-2
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.18.0-1
ii  libmate-menu2 1.18.1-1
ii  libmatekbd4   1.18.2-1
ii  libnotify40.7.7-3
ii  libpam0g  1.1.8-3.6
ii  libpango-1.0-01.40.14-1
ii  libpangocairo-1.0-0   1.40.14-1
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-5
ii  libsystemd0   236-3
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxklavier16 5.4-3
ii  libxss1   1:1.2.2-1+b2
ii  libxxf86vm1   1:1.1.4-1+b2
ii  mate-desktop-common   1.18.0-1
ii  mate-screensaver-common   1.18.2-1
ii  mate-session-manager  1.18.2-1

Versions of packages mate-screensaver recommends:
ii  mate-power-manager  1.18.1-2

Versions of packages mate-screensaver suggests:
pn  rss-glx
ii  xscreensaver-data  5.36-1

-- no debconf information

Bug#882513: gsequencer: autopkgtest is broken

[Joël Krähemann]

Hi,
My sponsor created a new package. It should be fixed now.
https://tracker.debian.org/news/893466

Bests,
Joël

On Sat, Nov 25, 2017 at 8:35 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi,
> Just provided a new upstream package v1.1.5 and made debian
> repository fit for autopkgtest.
>
> Best regards,
> Joël
>
>
> On Fri, Nov 24, 2017 at 10:55 AM, Joël Krähemann <jkraehem...@gmail.com> 
> wrote:
>> Hi,
>> Since I (upstream) doesn't have the infrastructure to run integration
>> tests configure.ac remains the same. But the fixes to the file
>> functional-system-tests.mk.am just applied upstream.
>>
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=1.2.x
>>
>> Bests,
>> Joël
>>
>>
>>
>> On Fri, Nov 24, 2017 at 10:50 AM, Joël Krähemann <jkraehem...@gmail.com> 
>> wrote:
>>> Hi,
>>> Just providing a patch. The target ags-integration-test wasn't take care
>>> much.
>>>
>>> Apply the patch fix-integration-tests.patch
>>> `patch -p1 < ../nongnu/gsequencer/fix-integration-tests.patch`
>>> run `autoreconf -fi && ./configure`
>>> then `make -j20 && make ags-integration-test`
>>>
>>> Bests,
>>> Joël
>>>
>>>
>>> On Fri, Nov 24, 2017 at 9:26 AM, Joël Krähemann <jkraehem...@gmail.com> 
>>> wrote:
>>>> Hi Dimitri,
>>>> The make target ags-integration-test runs against installed libraries. 
>>>> Just run
>>>> `make check` which contains the very same functional tests. But this 
>>>> requires
>>>> to remove the following patch:
>>>>
>>>> debian/patches/disable-functional-tests.patch
>>>>
>>>> `make ags-integration-test` is only useful to run against installed 
>>>> gsequencer
>>>> package. Further libgsequencer.so can't be a private library if you want 
>>>> to run
>>>> them. So additional patch would be required to change library installation 
>>>> path.
>>>>
>>>> Best regards,
>>>> Joël Krähemann
>>>>
>>>>
>>>> On Thu, Nov 23, 2017 at 5:01 PM, Dimitri John Ledkov <x...@ubuntu.com> 
>>>> wrote:
>>>>> Package: gsequencer
>>>>> Version: 1.1.4-1
>>>>> Severity: normal
>>>>>
>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>> Hash: SHA256
>>>>>
>>>>> Dear Maintainer,
>>>>>
>>>>> The autopkgtest included in gsequencer appears to not work at all
>>>>> anymore.
>>>>>
>>>>> It calls into debian/rules targets that do not exist anymore. I've
>>>>> tried fixing it up, by making the test depend on '@builddeps@` or
>>>>> using 'build-needed' restriction and modifying the test script
>>>>> appropriately only to see that `make ags-integration-test` fails.
>>>>>
>>>>> Could you please fix up integration test? Or remove it, as it cannot
>>>>> be executed anymore?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Dimitri.
>>>>>
>>>>> -BEGIN PGP SIGNATURE-
>>>>> Version: GnuPG v2
>>>>>
>>>>> iQEcBAEBCAAGBQJaFvDxAAoJEMrC2LnNLKX5is0IAIvh3irtF/gIk1rUVHo/yiqG
>>>>> 3o95sZobiNDufyayagCtEpNwhRG+lB1weeQADqUfLu7j3a3CiHra3a9ZZkNEIvBL
>>>>> OOs1tQj1wc9vy0SjQ37jwUbJ3NCjYLcr6WL5iwq4rnSfY/mBZsbGKEMoj6Hb3Kv/
>>>>> FZosTJtido/zOdyB+Xv1lwWnd0109l44Pz0MiY8oUlRqax/OX+jvfM+lkGFSRqDW
>>>>> tlRhFkMhpsRTTI6U/l1ajL5htmY6/gSgkZe6KkIyda+Uxbn+wY7mGLVHZCtGDw7c
>>>>> 6sAxfDSR2RaBOFFhpFkHDlfcloiJ2yUDZgn43xQv+cqzYBWChGtDZceZ0O/juXo=
>>>>> =zzou
>>>>> -END PGP SIGNATURE-
>>>>>

Bug#882513: gsequencer: autopkgtest is broken

[Joël Krähemann]

Hi,
Just provided a new upstream package v1.1.5 and made debian
repository fit for autopkgtest.

Best regards,
Joël


On Fri, Nov 24, 2017 at 10:55 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi,
> Since I (upstream) doesn't have the infrastructure to run integration
> tests configure.ac remains the same. But the fixes to the file
> functional-system-tests.mk.am just applied upstream.
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=1.2.x
>
> Bests,
> Joël
>
>
>
> On Fri, Nov 24, 2017 at 10:50 AM, Joël Krähemann <jkraehem...@gmail.com> 
> wrote:
>> Hi,
>> Just providing a patch. The target ags-integration-test wasn't take care
>> much.
>>
>> Apply the patch fix-integration-tests.patch
>> `patch -p1 < ../nongnu/gsequencer/fix-integration-tests.patch`
>> run `autoreconf -fi && ./configure`
>> then `make -j20 && make ags-integration-test`
>>
>> Bests,
>> Joël
>>
>>
>> On Fri, Nov 24, 2017 at 9:26 AM, Joël Krähemann <jkraehem...@gmail.com> 
>> wrote:
>>> Hi Dimitri,
>>> The make target ags-integration-test runs against installed libraries. Just 
>>> run
>>> `make check` which contains the very same functional tests. But this 
>>> requires
>>> to remove the following patch:
>>>
>>> debian/patches/disable-functional-tests.patch
>>>
>>> `make ags-integration-test` is only useful to run against installed 
>>> gsequencer
>>> package. Further libgsequencer.so can't be a private library if you want to 
>>> run
>>> them. So additional patch would be required to change library installation 
>>> path.
>>>
>>> Best regards,
>>> Joël Krähemann
>>>
>>>
>>> On Thu, Nov 23, 2017 at 5:01 PM, Dimitri John Ledkov <x...@ubuntu.com> 
>>> wrote:
>>>> Package: gsequencer
>>>> Version: 1.1.4-1
>>>> Severity: normal
>>>>
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA256
>>>>
>>>> Dear Maintainer,
>>>>
>>>> The autopkgtest included in gsequencer appears to not work at all
>>>> anymore.
>>>>
>>>> It calls into debian/rules targets that do not exist anymore. I've
>>>> tried fixing it up, by making the test depend on '@builddeps@` or
>>>> using 'build-needed' restriction and modifying the test script
>>>> appropriately only to see that `make ags-integration-test` fails.
>>>>
>>>> Could you please fix up integration test? Or remove it, as it cannot
>>>> be executed anymore?
>>>>
>>>> Regards,
>>>>
>>>> Dimitri.
>>>>
>>>> -BEGIN PGP SIGNATURE-
>>>> Version: GnuPG v2
>>>>
>>>> iQEcBAEBCAAGBQJaFvDxAAoJEMrC2LnNLKX5is0IAIvh3irtF/gIk1rUVHo/yiqG
>>>> 3o95sZobiNDufyayagCtEpNwhRG+lB1weeQADqUfLu7j3a3CiHra3a9ZZkNEIvBL
>>>> OOs1tQj1wc9vy0SjQ37jwUbJ3NCjYLcr6WL5iwq4rnSfY/mBZsbGKEMoj6Hb3Kv/
>>>> FZosTJtido/zOdyB+Xv1lwWnd0109l44Pz0MiY8oUlRqax/OX+jvfM+lkGFSRqDW
>>>> tlRhFkMhpsRTTI6U/l1ajL5htmY6/gSgkZe6KkIyda+Uxbn+wY7mGLVHZCtGDw7c
>>>> 6sAxfDSR2RaBOFFhpFkHDlfcloiJ2yUDZgn43xQv+cqzYBWChGtDZceZ0O/juXo=
>>>> =zzou
>>>> -END PGP SIGNATURE-
>>>>

Bug#882513: gsequencer: autopkgtest is broken

[Joël Krähemann]

Hi,
Since I (upstream) doesn't have the infrastructure to run integration
tests configure.ac remains the same. But the fixes to the file
functional-system-tests.mk.am just applied upstream.

http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=1.2.x

Bests,
Joël



On Fri, Nov 24, 2017 at 10:50 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi,
> Just providing a patch. The target ags-integration-test wasn't take care
> much.
>
> Apply the patch fix-integration-tests.patch
> `patch -p1 < ../nongnu/gsequencer/fix-integration-tests.patch`
> run `autoreconf -fi && ./configure`
> then `make -j20 && make ags-integration-test`
>
> Bests,
> Joël
>
>
> On Fri, Nov 24, 2017 at 9:26 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
>> Hi Dimitri,
>> The make target ags-integration-test runs against installed libraries. Just 
>> run
>> `make check` which contains the very same functional tests. But this requires
>> to remove the following patch:
>>
>> debian/patches/disable-functional-tests.patch
>>
>> `make ags-integration-test` is only useful to run against installed 
>> gsequencer
>> package. Further libgsequencer.so can't be a private library if you want to 
>> run
>> them. So additional patch would be required to change library installation 
>> path.
>>
>> Best regards,
>> Joël Krähemann
>>
>>
>> On Thu, Nov 23, 2017 at 5:01 PM, Dimitri John Ledkov <x...@ubuntu.com> wrote:
>>> Package: gsequencer
>>> Version: 1.1.4-1
>>> Severity: normal
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Dear Maintainer,
>>>
>>> The autopkgtest included in gsequencer appears to not work at all
>>> anymore.
>>>
>>> It calls into debian/rules targets that do not exist anymore. I've
>>> tried fixing it up, by making the test depend on '@builddeps@` or
>>> using 'build-needed' restriction and modifying the test script
>>> appropriately only to see that `make ags-integration-test` fails.
>>>
>>> Could you please fix up integration test? Or remove it, as it cannot
>>> be executed anymore?
>>>
>>> Regards,
>>>
>>> Dimitri.
>>>
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJaFvDxAAoJEMrC2LnNLKX5is0IAIvh3irtF/gIk1rUVHo/yiqG
>>> 3o95sZobiNDufyayagCtEpNwhRG+lB1weeQADqUfLu7j3a3CiHra3a9ZZkNEIvBL
>>> OOs1tQj1wc9vy0SjQ37jwUbJ3NCjYLcr6WL5iwq4rnSfY/mBZsbGKEMoj6Hb3Kv/
>>> FZosTJtido/zOdyB+Xv1lwWnd0109l44Pz0MiY8oUlRqax/OX+jvfM+lkGFSRqDW
>>> tlRhFkMhpsRTTI6U/l1ajL5htmY6/gSgkZe6KkIyda+Uxbn+wY7mGLVHZCtGDw7c
>>> 6sAxfDSR2RaBOFFhpFkHDlfcloiJ2yUDZgn43xQv+cqzYBWChGtDZceZ0O/juXo=
>>> =zzou
>>> -END PGP SIGNATURE-
>>>

Bug#882513: gsequencer: autopkgtest is broken

[Joël Krähemann]

Hi,
Just providing a patch. The target ags-integration-test wasn't take care
much.

Apply the patch fix-integration-tests.patch
`patch -p1 < ../nongnu/gsequencer/fix-integration-tests.patch`
run `autoreconf -fi && ./configure`
then `make -j20 && make ags-integration-test`

Bests,
Joël


On Fri, Nov 24, 2017 at 9:26 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi Dimitri,
> The make target ags-integration-test runs against installed libraries. Just 
> run
> `make check` which contains the very same functional tests. But this requires
> to remove the following patch:
>
> debian/patches/disable-functional-tests.patch
>
> `make ags-integration-test` is only useful to run against installed gsequencer
> package. Further libgsequencer.so can't be a private library if you want to 
> run
> them. So additional patch would be required to change library installation 
> path.
>
> Best regards,
> Joël Krähemann
>
>
> On Thu, Nov 23, 2017 at 5:01 PM, Dimitri John Ledkov <x...@ubuntu.com> wrote:
>> Package: gsequencer
>> Version: 1.1.4-1
>> Severity: normal
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Dear Maintainer,
>>
>> The autopkgtest included in gsequencer appears to not work at all
>> anymore.
>>
>> It calls into debian/rules targets that do not exist anymore. I've
>> tried fixing it up, by making the test depend on '@builddeps@` or
>> using 'build-needed' restriction and modifying the test script
>> appropriately only to see that `make ags-integration-test` fails.
>>
>> Could you please fix up integration test? Or remove it, as it cannot
>> be executed anymore?
>>
>> Regards,
>>
>> Dimitri.
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJaFvDxAAoJEMrC2LnNLKX5is0IAIvh3irtF/gIk1rUVHo/yiqG
>> 3o95sZobiNDufyayagCtEpNwhRG+lB1weeQADqUfLu7j3a3CiHra3a9ZZkNEIvBL
>> OOs1tQj1wc9vy0SjQ37jwUbJ3NCjYLcr6WL5iwq4rnSfY/mBZsbGKEMoj6Hb3Kv/
>> FZosTJtido/zOdyB+Xv1lwWnd0109l44Pz0MiY8oUlRqax/OX+jvfM+lkGFSRqDW
>> tlRhFkMhpsRTTI6U/l1ajL5htmY6/gSgkZe6KkIyda+Uxbn+wY7mGLVHZCtGDw7c
>> 6sAxfDSR2RaBOFFhpFkHDlfcloiJ2yUDZgn43xQv+cqzYBWChGtDZceZ0O/juXo=
>> =zzou
>> -END PGP SIGNATURE-
>>
diff --git a/configure.ac b/configure.ac
index 429342efd..1b77b0073 100644
--- a/configure.ac
+++ b/configure.ac
@@ -272,6 +272,7 @@ AM_CONDITIONAL([ENABLE_GTK_DOC], false)
 
 AM_EXTRA_RECURSIVE_TARGETS([ags-docs])
 AC_CONFIG_FILES([
+functional-system-tests.mk
 Makefile
 docs/reference/libags/Makefile
 docs/reference/libags-audio/Makefile
diff --git a/functional-system-tests.mk.am b/functional-system-tests.mk.am
index 1dba004e6..22579aaa7 100644
--- a/functional-system-tests.mk.am
+++ b/functional-system-tests.mk.am
@@ -10,6 +10,11 @@ libgsequencer_check_system_test_LIBADD = -L$(libdir) -lags -lags_thread -lags_se
 
 gsequencer_check_system_functional_test_LDADD = -lags -lags_thread -lags_server -lags_audio -lags_gui -L$(DESTDIR)/$(libdir)/gsequencer/ -lgsequencer libgsequencer_check_system_test.la -lcunit -lrt -lm $(LIBAO_LIBS) $(LIBASOUND2_LIBS) $(LIBXML2_LIBS) $(SNDFILE_LIBS) $(LIBINSTPATCH_LIBS) $(GOBJECT_LIBS) $(JACK_LIBS) $(FONTCONFIG_LIBS) $(GDKPIXBUF_LIBS) $(CAIRO_LIBS) $(GTK_LIBS)
 
+localedir = $(datadir)/locale
+DEFS = -DLOCALEDIR=\"$(localedir)\" @DEFS@
+
+AGS_RESOURCES = -DAGS_RC_FILENAME=\"/usr/share/gsequencer/styles/ags.rc\" -DAGS_ANIMATION_FILENAME=\"/usr/share/gsequencer/images/ags_supermoon-800x450.png\" -DAGS_LOGO_FILENAME=\"/usr/share/gsequencer/images/ags.png\" -DAGS_LICENSE_FILENAME=\"/usr/share/common-licenses/GPL-3\"
+
 noinst_LTLIBRARIES = libgsequencer_check_system_test.la
 
 # functional system tests - edit target
@@ -32,7 +37,7 @@ noinst_PROGRAMS = $(installcheck_programs)
 # functional test util library
 libgsequencer_check_system_test_la_SOURCES = ags/test/X/gsequencer_setup_util.c ags/test/X/gsequencer_setup_util.h ags/test/X/ags_functional_test_util.c ags/test/X/ags_functional_test_util.h ags/test/X/libgsequencer.h
 libgsequencer_check_system_test_la_CFLAGS = $(CFLAGS) $(LIBAO_CFLAGS) $(LIBASOUND2_CFLAGS) $(LIBXML2_CFLAGS) $(SNDFILE_CFLAGS) $(LIBINSTPATCH_CFLAGS) $(GOBJECT_CFLAGS) $(JACK_CFLAGS) $(FONTCONFIG_CFLAGS) $(GDKPIXBUF_CFLAGS) $(CAIRO_CFLAGS) $(GTK_CFLAGS)
-libgsequencer_check_system_test_la_CPPFLAGS = -DSRCDIR=\"$(srcdir)\"
+libgsequencer_check_system_test_la_CPPFLAGS = -DSRCDIR=\"$(srcdir)\" $(AGS_RESOURCES)
 libgsequencer_check_system_test_la_LIBADD = $(libgsequencer_check_system_test_LIBADD)
 
 # functional audio test
@@ -44,77 +49,77 @@ ags_check_system_functional_audio_test_LDADD = $(gsequencer_check_system_functio
 # functional machine add and destroy test
 ags_check_system_function

Bug#882513: gsequencer: autopkgtest is broken

[Joël Krähemann]

Hi Dimitri,
The make target ags-integration-test runs against installed libraries. Just run
`make check` which contains the very same functional tests. But this requires
to remove the following patch:

debian/patches/disable-functional-tests.patch

`make ags-integration-test` is only useful to run against installed gsequencer
package. Further libgsequencer.so can't be a private library if you want to run
them. So additional patch would be required to change library installation path.

Best regards,
Joël Krähemann


On Thu, Nov 23, 2017 at 5:01 PM, Dimitri John Ledkov <x...@ubuntu.com> wrote:
> Package: gsequencer
> Version: 1.1.4-1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Dear Maintainer,
>
> The autopkgtest included in gsequencer appears to not work at all
> anymore.
>
> It calls into debian/rules targets that do not exist anymore. I've
> tried fixing it up, by making the test depend on '@builddeps@` or
> using 'build-needed' restriction and modifying the test script
> appropriately only to see that `make ags-integration-test` fails.
>
> Could you please fix up integration test? Or remove it, as it cannot
> be executed anymore?
>
> Regards,
>
> Dimitri.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJaFvDxAAoJEMrC2LnNLKX5is0IAIvh3irtF/gIk1rUVHo/yiqG
> 3o95sZobiNDufyayagCtEpNwhRG+lB1weeQADqUfLu7j3a3CiHra3a9ZZkNEIvBL
> OOs1tQj1wc9vy0SjQ37jwUbJ3NCjYLcr6WL5iwq4rnSfY/mBZsbGKEMoj6Hb3Kv/
> FZosTJtido/zOdyB+Xv1lwWnd0109l44Pz0MiY8oUlRqax/OX+jvfM+lkGFSRqDW
> tlRhFkMhpsRTTI6U/l1ajL5htmY6/gSgkZe6KkIyda+Uxbn+wY7mGLVHZCtGDw7c
> 6sAxfDSR2RaBOFFhpFkHDlfcloiJ2yUDZgn43xQv+cqzYBWChGtDZceZ0O/juXo=
> =zzou
> -END PGP SIGNATURE-
>

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[Joël Krähemann]

Hi

Code like this might destabilize the operating system and compromise debian.
There is a good reason why glib-2.0 uses void pointers.

Bests,
Joël


On Fri, Aug 11, 2017 at 9:23 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> Might be just a programming error. But it is important that you don't point
> uint8_t pointer to a struct.
>
> Might be some language basics missing?
>
> It is the same for atoms. Just use void pointers, please.
>
> Bests,
> Joël
>
>
> On Fri, Aug 11, 2017 at 8:52 PM, Robin Gareus <ro...@gareus.org> wrote:
>> Note that the LV2 event extension was deprecated years ago
>> and the last plugins which were using it were /killed/ in 2014.
>>
>> http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2014-January/000642.html
>>
>>
>> As for the bug report itself, changing plugin API specifications
>> post-factum is never a good idea. So uint8_t it is, besides the
>> documentation in event.h makes it clear:
>>
>> /**
>> The contents of the event buffer. This may or may not reside in the
>> same block of memory as this header, plugins must not assume either.
>> The host guarantees this points to at least capacity bytes of allocated
>> memory (though only size bytes of that are valid events).
>> */
>> uint8_t* data;
>>
>>
>> not a bug.
>>
>> On 08/11/2017 08:20 PM, Joël Krähemann wrote:
>>> Hi
>>>
>>> For sure you can cast any pointer. But feels somehow wrong. The
>>> opinion was the specs
>>> are always correct.
>>>
>>> Bests,
>>> Joël
>>>
>>
>> ___
>> pkg-multimedia-maintainers mailing list
>> pkg-multimedia-maintain...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[Joël Krähemann]

Hi

Might be just a programming error. But it is important that you don't point
uint8_t pointer to a struct.

Might be some language basics missing?

It is the same for atoms. Just use void pointers, please.

Bests,
Joël


On Fri, Aug 11, 2017 at 8:52 PM, Robin Gareus <ro...@gareus.org> wrote:
> Note that the LV2 event extension was deprecated years ago
> and the last plugins which were using it were /killed/ in 2014.
>
> http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2014-January/000642.html
>
>
> As for the bug report itself, changing plugin API specifications
> post-factum is never a good idea. So uint8_t it is, besides the
> documentation in event.h makes it clear:
>
> /**
> The contents of the event buffer. This may or may not reside in the
> same block of memory as this header, plugins must not assume either.
> The host guarantees this points to at least capacity bytes of allocated
> memory (though only size bytes of that are valid events).
> */
> uint8_t* data;
>
>
> not a bug.
>
> On 08/11/2017 08:20 PM, Joël Krähemann wrote:
>> Hi
>>
>> For sure you can cast any pointer. But feels somehow wrong. The
>> opinion was the specs
>> are always correct.
>>
>> Bests,
>> Joël
>>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[Joël Krähemann]

Hi

For sure you can cast any pointer. But feels somehow wrong. The
opinion was the specs
are always correct.

Bests,
Joël


On Fri, Aug 11, 2017 at 8:12 PM, Jaromír Mikeš <mira.mi...@gmail.com> wrote:
>
>
> 2017-08-10 16:23 GMT+02:00 Joël Krähemann <jkraehem...@gmail.com>:
>>
>> Hi James,
>>
>> It is common that you use for storing uint8_t an entire word.
>> The use of a uint8_t pointer confused me as you are pointing
>> to a struct.
>>
>> Bests,
>> Joël
>>
>>
>> On Thu, Aug 10, 2017 at 4:10 PM, James Cowgill <jcowg...@debian.org>
>> wrote:
>> > Hi,
>> >
>> > On 10/08/17 08:31, Joël Krähemann wrote:
>> >> Package: lv2-dev
>> >> Version: 1.14.0~dfsg1-1
>> >> Severity: important
>> >>
>> >> Dear Maintainer,
>> >>
>> >> The following header makes use of smallest possible pointer in
>> >> LV2_Event_Buffer struct's data field.
>> >>
>> >> lv2/lv2plug.in/ns/ext/event/event.h
>> >>
>> >> Please change it to biggest possible pointer. It should be definitely
>> >> void* type because the memory
>> >> pointed by data shall contain another struct LV2_Event.
>> >>
>> >> This describes an integer overflow. There shouldn't be any overflow.
>> >
>> > I'm afraid I don't see what the problem is here, or where the integer
>> > overflow is. The data field is casted to an appropriate pointer type
>> > whenever it is used and doing that is portable if you're careful.
>>
>
> Hi Joel,
>
> You still think it is a bug?
> Did you contacted upstream author about this issue already?
>
> best regards
>
> mira
>

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[Joël Krähemann]

Hi James,

It is common that you use for storing uint8_t an entire word.
The use of a uint8_t pointer confused me as you are pointing
to a struct.

Bests,
Joël


On Thu, Aug 10, 2017 at 4:10 PM, James Cowgill <jcowg...@debian.org> wrote:
> Hi,
>
> On 10/08/17 08:31, Joël Krähemann wrote:
>> Package: lv2-dev
>> Version: 1.14.0~dfsg1-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> The following header makes use of smallest possible pointer in 
>> LV2_Event_Buffer struct's data field.
>>
>> lv2/lv2plug.in/ns/ext/event/event.h
>>
>> Please change it to biggest possible pointer. It should be definitely void* 
>> type because the memory
>> pointed by data shall contain another struct LV2_Event.
>>
>> This describes an integer overflow. There shouldn't be any overflow.
>
> I'm afraid I don't see what the problem is here, or where the integer
> overflow is. The data field is casted to an appropriate pointer type
> whenever it is used and doing that is portable if you're careful.
>
> Thanks,
> James
>

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[Joël Krähemann]

Package: lv2-dev
Version: 1.14.0~dfsg1-1
Severity: important

Dear Maintainer,

The following header makes use of smallest possible pointer in LV2_Event_Buffer 
struct's data field.

lv2/lv2plug.in/ns/ext/event/event.h

Please change it to biggest possible pointer. It should be definitely void* 
type because the memory
pointed by data shall contain another struct LV2_Event.

This describes an integer overflow. There shouldn't be any overflow.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#869152: lv2-dev: type conflict of and

[Joël Krähemann]

Package: lv2-dev
Version: 1.14.0~dfsg1-1
Severity: important

Dear Maintainer,

As doing #include  before  I get following compiler errors:

/usr/lib/lv2/atom.lv2/forge.h:114:11: error: two or more data types in 
declaration specifiers
LV2_URID Bool;
^
/usr/lib/lv2/atom.lv2/forge.h: In function 'lv2_atom_forge_init':
/usr/lib/lv2/atom.lv2/forge.h:147:9: error: expected identifier before 'int'
forge->Bool = map->map(map->handle, LV2_ATOM__Bool);
^
/usr/lib/lv2/atom.lv2/forge.h: In function 'lv2_atom_forge_bool':
/usr/lib/lv2/atom.lv2/forge.h:408:54: error: expected identifier before 'int'
const LV2_Atom_Bool a = { { sizeof(int32_t), forge->Bool }, val ? 1 : 0 };
^

The compilation of my program aborted with the above error message. However
as swapping the include order, it compiles.

I was expecting no conflict in the header files.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#861908: gsequencer: testsuite crashes if AddressSanitizer is enabled

[Joël Krähemann]

Hi

I have targeted the issue during release of gsequencer-0.8.7.
I think we should close this bug.

Bests,
Joël


On Mon, May 22, 2017 at 12:19 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> Just figured out that are mainly issues related
> to memory leakes within the test that can be
> safely ignored.
>
> Note I have fixed additional issues with this
> test:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=0.8.x=78e7b1877add068e59b18b13e2e3b4e245e0b3d3
>
>
> On Sun, May 21, 2017 at 11:38 PM, Joël Krähemann <jkraehem...@gmail.com> 
> wrote:
>> Hi
>>
>> Just recognized every _ unit test fails.
>> So I'm busy for a while.
>>
>> Cheers,
>> Joël
>>
>>
>> On Sun, May 21, 2017 at 11:15 PM, Joël Krähemann <jkraehem...@gmail.com> 
>> wrote:
>>> Hi
>>>
>>> the stack-trace above should be fixed commit:
>>>
>>> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=0.8.x=d6a5a226fa01525bbcce3824dfb5f7e82767eb62
>>>
>>> Since I didn't test with address sanitizer this wasn't recognized.
>>> I just do run it now. Might be there other issues.
>>>
>>> Bests,
>>> Joël
>>>
>>>
>>> On Fri, May 5, 2017 at 6:06 PM, James Cowgill <jcowg...@debian.org> wrote:
>>>> Source: gsequencer
>>>> Version: 0.8.0-1
>>>> Severity: important
>>>>
>>>> Hi,
>>>>
>>>> While looking at #861645 I noticed that the gsequencer testsuite
>>>> crashes on x86 with a heap buffer overflow when AddressSanitizer
>>>> (-fsanitize=address) is enabled.
>>>>
>>>>
>>>> FAIL: ags_midi_buffer_util_test
>>>> ===
>>>>
>>>>
>>>>
>>>>  CUnit - A unit testing framework for C - Version 2.1-3
>>>>  http://cunit.sourceforge.net/
>>>>
>>>>
>>>> Suite: AgsMidiBufferUtilTest
>>>>   Test: test of ags_midi_buffer_util.c get varlength size ...passed
>>>>   Test: test of ags_midi_buffer_util.c put varlength ...passed
>>>>   Test: test of ags_midi_buffer_util.c get varlength ...passed
>>>>   Test: test of ags_midi_buffer_util.c put int16 ...passed
>>>>   Test: test of ags_midi_buffer_util.c get int16 ...passed
>>>>   Test: test of ags_midi_buffer_util.c put int24 ...passed
>>>>   Test: test of ags_midi_buffer_util.c get int24 ...passed
>>>>   Test: test of ags_midi_buffer_util.c put int32 ...passed
>>>>   Test: test of ags_midi_buffer_util.c get int32 ...passed
>>>>   Test: test of ags_midi_buffer_util.c put header ...
>>>> ** (process:4236): WARNING **: invalid chunk length
>>>>
>>>> ** (process:4236): WARNING **: invalid chunk length
>>>> FAILED
>>>> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:518  - success == 
>>>> TRUE
>>>> 2. ags/test/audio/midi/ags_midi_buffer_util_test.c:535  - success == 
>>>> TRUE
>>>>   Test: test of ags_midi_buffer_util.c get header ...passed
>>>>   Test: test of ags_midi_buffer_util.c put track ...passed
>>>>   Test: test of ags_midi_buffer_util.c get track ...passed
>>>>   Test: test of ags_midi_buffer_util.c put key on ...passed
>>>>   Test: test of ags_midi_buffer_util.c get key on ...passed
>>>>   Test: test of ags_midi_buffer_util.c put key off ...passed
>>>>   Test: test of ags_midi_buffer_util.c get key off ...passed
>>>>   Test: test of ags_midi_buffer_util.c put key pressure ...passed
>>>>   Test: test of ags_midi_buffer_util.c get key pressure ...passed
>>>>   Test: test of ags_midi_buffer_util.c put change parameter ...passed
>>>>   Test: test of ags_midi_buffer_util.c get change parameter ...passed
>>>>   Test: test of ags_midi_buffer_util.c put change pitch bend ...passed
>>>>   Test: test of ags_midi_buffer_util.c get change pitch bend ...passed
>>>>   Test: test of ags_midi_buffer_util.c put change program ...FAILED
>>>> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:1044  - success == 
>>>> TRUE
>>>>   Test: test of ags_midi_buffer_util.c get change program 
>>>> ...=
>>>> ==4236==ERROR: AddressSanitizer: heap-buffer-overflow on address 
>>>> 0x6020dff6 at pc 0x7f0b047bfd7b bp 0x7fff86d9a050 sp 0x7fff86d99800
>>>&

Bug#861908: gsequencer: testsuite crashes if AddressSanitizer is enabled

[Joël Krähemann]

Hi

Just figured out that are mainly issues related
to memory leakes within the test that can be
safely ignored.

Note I have fixed additional issues with this
test:

http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=0.8.x=78e7b1877add068e59b18b13e2e3b4e245e0b3d3


On Sun, May 21, 2017 at 11:38 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> Just recognized every _ unit test fails.
> So I'm busy for a while.
>
> Cheers,
> Joël
>
>
> On Sun, May 21, 2017 at 11:15 PM, Joël Krähemann <jkraehem...@gmail.com> 
> wrote:
>> Hi
>>
>> the stack-trace above should be fixed commit:
>>
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=0.8.x=d6a5a226fa01525bbcce3824dfb5f7e82767eb62
>>
>> Since I didn't test with address sanitizer this wasn't recognized.
>> I just do run it now. Might be there other issues.
>>
>> Bests,
>> Joël
>>
>>
>> On Fri, May 5, 2017 at 6:06 PM, James Cowgill <jcowg...@debian.org> wrote:
>>> Source: gsequencer
>>> Version: 0.8.0-1
>>> Severity: important
>>>
>>> Hi,
>>>
>>> While looking at #861645 I noticed that the gsequencer testsuite
>>> crashes on x86 with a heap buffer overflow when AddressSanitizer
>>> (-fsanitize=address) is enabled.
>>>
>>>
>>> FAIL: ags_midi_buffer_util_test
>>> ===
>>>
>>>
>>>
>>>  CUnit - A unit testing framework for C - Version 2.1-3
>>>  http://cunit.sourceforge.net/
>>>
>>>
>>> Suite: AgsMidiBufferUtilTest
>>>   Test: test of ags_midi_buffer_util.c get varlength size ...passed
>>>   Test: test of ags_midi_buffer_util.c put varlength ...passed
>>>   Test: test of ags_midi_buffer_util.c get varlength ...passed
>>>   Test: test of ags_midi_buffer_util.c put int16 ...passed
>>>   Test: test of ags_midi_buffer_util.c get int16 ...passed
>>>   Test: test of ags_midi_buffer_util.c put int24 ...passed
>>>   Test: test of ags_midi_buffer_util.c get int24 ...passed
>>>   Test: test of ags_midi_buffer_util.c put int32 ...passed
>>>   Test: test of ags_midi_buffer_util.c get int32 ...passed
>>>   Test: test of ags_midi_buffer_util.c put header ...
>>> ** (process:4236): WARNING **: invalid chunk length
>>>
>>> ** (process:4236): WARNING **: invalid chunk length
>>> FAILED
>>> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:518  - success == 
>>> TRUE
>>> 2. ags/test/audio/midi/ags_midi_buffer_util_test.c:535  - success == 
>>> TRUE
>>>   Test: test of ags_midi_buffer_util.c get header ...passed
>>>   Test: test of ags_midi_buffer_util.c put track ...passed
>>>   Test: test of ags_midi_buffer_util.c get track ...passed
>>>   Test: test of ags_midi_buffer_util.c put key on ...passed
>>>   Test: test of ags_midi_buffer_util.c get key on ...passed
>>>   Test: test of ags_midi_buffer_util.c put key off ...passed
>>>   Test: test of ags_midi_buffer_util.c get key off ...passed
>>>   Test: test of ags_midi_buffer_util.c put key pressure ...passed
>>>   Test: test of ags_midi_buffer_util.c get key pressure ...passed
>>>   Test: test of ags_midi_buffer_util.c put change parameter ...passed
>>>   Test: test of ags_midi_buffer_util.c get change parameter ...passed
>>>   Test: test of ags_midi_buffer_util.c put change pitch bend ...passed
>>>   Test: test of ags_midi_buffer_util.c get change pitch bend ...passed
>>>   Test: test of ags_midi_buffer_util.c put change program ...FAILED
>>> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:1044  - success == 
>>> TRUE
>>>   Test: test of ags_midi_buffer_util.c get change program 
>>> ...=
>>> ==4236==ERROR: AddressSanitizer: heap-buffer-overflow on address 
>>> 0x6020dff6 at pc 0x7f0b047bfd7b bp 0x7fff86d9a050 sp 0x7fff86d99800
>>> WRITE of size 3 at 0x6020dff6 thread T0
>>> #0 0x7f0b047bfd7a  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a)
>>> #1 0x5618bff665ad in memcpy 
>>> /usr/include/x86_64-linux-gnu/bits/string3.h:53
>>> #2 0x5618bff665ad in ags_midi_buffer_util_test_get_change_program 
>>> ags/test/audio/midi/ags_midi_buffer_util_test.c:1073
>>> #3 0x7f0b03741396  (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x4396)
>>> #4 0x7f0b037416cf  (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x46cf)
>>> #5 0x7f0b03741a1d in CU_run_all_te

Bug#861908: gsequencer: testsuite crashes if AddressSanitizer is enabled

[Joël Krähemann]

Hi

Just recognized every _ unit test fails.
So I'm busy for a while.

Cheers,
Joël


On Sun, May 21, 2017 at 11:15 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> the stack-trace above should be fixed commit:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=0.8.x=d6a5a226fa01525bbcce3824dfb5f7e82767eb62
>
> Since I didn't test with address sanitizer this wasn't recognized.
> I just do run it now. Might be there other issues.
>
> Bests,
> Joël
>
>
> On Fri, May 5, 2017 at 6:06 PM, James Cowgill <jcowg...@debian.org> wrote:
>> Source: gsequencer
>> Version: 0.8.0-1
>> Severity: important
>>
>> Hi,
>>
>> While looking at #861645 I noticed that the gsequencer testsuite
>> crashes on x86 with a heap buffer overflow when AddressSanitizer
>> (-fsanitize=address) is enabled.
>>
>>
>> FAIL: ags_midi_buffer_util_test
>> ===
>>
>>
>>
>>  CUnit - A unit testing framework for C - Version 2.1-3
>>  http://cunit.sourceforge.net/
>>
>>
>> Suite: AgsMidiBufferUtilTest
>>   Test: test of ags_midi_buffer_util.c get varlength size ...passed
>>   Test: test of ags_midi_buffer_util.c put varlength ...passed
>>   Test: test of ags_midi_buffer_util.c get varlength ...passed
>>   Test: test of ags_midi_buffer_util.c put int16 ...passed
>>   Test: test of ags_midi_buffer_util.c get int16 ...passed
>>   Test: test of ags_midi_buffer_util.c put int24 ...passed
>>   Test: test of ags_midi_buffer_util.c get int24 ...passed
>>   Test: test of ags_midi_buffer_util.c put int32 ...passed
>>   Test: test of ags_midi_buffer_util.c get int32 ...passed
>>   Test: test of ags_midi_buffer_util.c put header ...
>> ** (process:4236): WARNING **: invalid chunk length
>>
>> ** (process:4236): WARNING **: invalid chunk length
>> FAILED
>> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:518  - success == TRUE
>> 2. ags/test/audio/midi/ags_midi_buffer_util_test.c:535  - success == TRUE
>>   Test: test of ags_midi_buffer_util.c get header ...passed
>>   Test: test of ags_midi_buffer_util.c put track ...passed
>>   Test: test of ags_midi_buffer_util.c get track ...passed
>>   Test: test of ags_midi_buffer_util.c put key on ...passed
>>   Test: test of ags_midi_buffer_util.c get key on ...passed
>>   Test: test of ags_midi_buffer_util.c put key off ...passed
>>   Test: test of ags_midi_buffer_util.c get key off ...passed
>>   Test: test of ags_midi_buffer_util.c put key pressure ...passed
>>   Test: test of ags_midi_buffer_util.c get key pressure ...passed
>>   Test: test of ags_midi_buffer_util.c put change parameter ...passed
>>   Test: test of ags_midi_buffer_util.c get change parameter ...passed
>>   Test: test of ags_midi_buffer_util.c put change pitch bend ...passed
>>   Test: test of ags_midi_buffer_util.c get change pitch bend ...passed
>>   Test: test of ags_midi_buffer_util.c put change program ...FAILED
>> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:1044  - success == 
>> TRUE
>>   Test: test of ags_midi_buffer_util.c get change program 
>> ...=
>> ==4236==ERROR: AddressSanitizer: heap-buffer-overflow on address 
>> 0x6020dff6 at pc 0x7f0b047bfd7b bp 0x7fff86d9a050 sp 0x7fff86d99800
>> WRITE of size 3 at 0x6020dff6 thread T0
>> #0 0x7f0b047bfd7a  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a)
>> #1 0x5618bff665ad in memcpy 
>> /usr/include/x86_64-linux-gnu/bits/string3.h:53
>> #2 0x5618bff665ad in ags_midi_buffer_util_test_get_change_program 
>> ags/test/audio/midi/ags_midi_buffer_util_test.c:1073
>> #3 0x7f0b03741396  (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x4396)
>> #4 0x7f0b037416cf  (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x46cf)
>> #5 0x7f0b03741a1d in CU_run_all_tests 
>> (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x4a1d)
>> #6 0x5618bff63203 in main 
>> ags/test/audio/midi/ags_midi_buffer_util_test.c:3257
>> #7 0x7f0b00fdb2b0 in __libc_start_main 
>> (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
>> #8 0x5618bff63269 in _start 
>> (/build/gsequencer-8YtPr4/gsequencer-0.8.0/.libs/ags_midi_buffer_util_test+0x7269)
>>
>> 0x6020dff6 is located 0 bytes to the right of 6-byte region 
>> [0x6020dff0,0x6020dff6)
>> allocated by thread T0 here:
>> #0 0x7f0b04824d28 in malloc 
>> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
>> #1 0x5618bff663ff in ags_midi_buffer_util_test_get_change_program 
>> ags/te

Bug#861908: gsequencer: testsuite crashes if AddressSanitizer is enabled

[Joël Krähemann]

Hi

the stack-trace above should be fixed commit:

http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=0.8.x=d6a5a226fa01525bbcce3824dfb5f7e82767eb62

Since I didn't test with address sanitizer this wasn't recognized.
I just do run it now. Might be there other issues.

Bests,
Joël


On Fri, May 5, 2017 at 6:06 PM, James Cowgill  wrote:
> Source: gsequencer
> Version: 0.8.0-1
> Severity: important
>
> Hi,
>
> While looking at #861645 I noticed that the gsequencer testsuite
> crashes on x86 with a heap buffer overflow when AddressSanitizer
> (-fsanitize=address) is enabled.
>
>
> FAIL: ags_midi_buffer_util_test
> ===
>
>
>
>  CUnit - A unit testing framework for C - Version 2.1-3
>  http://cunit.sourceforge.net/
>
>
> Suite: AgsMidiBufferUtilTest
>   Test: test of ags_midi_buffer_util.c get varlength size ...passed
>   Test: test of ags_midi_buffer_util.c put varlength ...passed
>   Test: test of ags_midi_buffer_util.c get varlength ...passed
>   Test: test of ags_midi_buffer_util.c put int16 ...passed
>   Test: test of ags_midi_buffer_util.c get int16 ...passed
>   Test: test of ags_midi_buffer_util.c put int24 ...passed
>   Test: test of ags_midi_buffer_util.c get int24 ...passed
>   Test: test of ags_midi_buffer_util.c put int32 ...passed
>   Test: test of ags_midi_buffer_util.c get int32 ...passed
>   Test: test of ags_midi_buffer_util.c put header ...
> ** (process:4236): WARNING **: invalid chunk length
>
> ** (process:4236): WARNING **: invalid chunk length
> FAILED
> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:518  - success == TRUE
> 2. ags/test/audio/midi/ags_midi_buffer_util_test.c:535  - success == TRUE
>   Test: test of ags_midi_buffer_util.c get header ...passed
>   Test: test of ags_midi_buffer_util.c put track ...passed
>   Test: test of ags_midi_buffer_util.c get track ...passed
>   Test: test of ags_midi_buffer_util.c put key on ...passed
>   Test: test of ags_midi_buffer_util.c get key on ...passed
>   Test: test of ags_midi_buffer_util.c put key off ...passed
>   Test: test of ags_midi_buffer_util.c get key off ...passed
>   Test: test of ags_midi_buffer_util.c put key pressure ...passed
>   Test: test of ags_midi_buffer_util.c get key pressure ...passed
>   Test: test of ags_midi_buffer_util.c put change parameter ...passed
>   Test: test of ags_midi_buffer_util.c get change parameter ...passed
>   Test: test of ags_midi_buffer_util.c put change pitch bend ...passed
>   Test: test of ags_midi_buffer_util.c get change pitch bend ...passed
>   Test: test of ags_midi_buffer_util.c put change program ...FAILED
> 1. ags/test/audio/midi/ags_midi_buffer_util_test.c:1044  - success == TRUE
>   Test: test of ags_midi_buffer_util.c get change program 
> ...=
> ==4236==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x6020dff6 at pc 0x7f0b047bfd7b bp 0x7fff86d9a050 sp 0x7fff86d99800
> WRITE of size 3 at 0x6020dff6 thread T0
> #0 0x7f0b047bfd7a  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a)
> #1 0x5618bff665ad in memcpy 
> /usr/include/x86_64-linux-gnu/bits/string3.h:53
> #2 0x5618bff665ad in ags_midi_buffer_util_test_get_change_program 
> ags/test/audio/midi/ags_midi_buffer_util_test.c:1073
> #3 0x7f0b03741396  (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x4396)
> #4 0x7f0b037416cf  (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x46cf)
> #5 0x7f0b03741a1d in CU_run_all_tests 
> (/usr/lib/x86_64-linux-gnu/libcunit.so.1+0x4a1d)
> #6 0x5618bff63203 in main 
> ags/test/audio/midi/ags_midi_buffer_util_test.c:3257
> #7 0x7f0b00fdb2b0 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
> #8 0x5618bff63269 in _start 
> (/build/gsequencer-8YtPr4/gsequencer-0.8.0/.libs/ags_midi_buffer_util_test+0x7269)
>
> 0x6020dff6 is located 0 bytes to the right of 6-byte region 
> [0x6020dff0,0x6020dff6)
> allocated by thread T0 here:
> #0 0x7f0b04824d28 in malloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
> #1 0x5618bff663ff in ags_midi_buffer_util_test_get_change_program 
> ags/test/audio/midi/ags_midi_buffer_util_test.c:1057
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cd7a)
> Shadow bytes around the buggy address:
>   0x0c047fff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c047fff9be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> =>0x0c047fff9bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[06]fa
>   0x0c047fff9c00: fa fa 00 00 fa fa 06 fa fa fa 07 fa fa fa 07 fa
>   0x0c047fff9c10: fa fa 07 fa fa fa 07 fa fa fa 07 fa fa fa 07 fa
>   0x0c047fff9c20: fa fa 07 fa fa fa 07 fa fa fa 07 fa fa fa 07 fa
>   

Bug#861645: gsequencer FTBFS on mips/mipsel: FAIL: ags_xorg_application_context_test

[Joël Krähemann]

Hi again

Sorry wrong context. It is the problem for sure:
Since it is used by AgsAutomationEditor, too.

Joël


On Fri, May 5, 2017 at 6:31 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> The flag was set. However it is not that beautiful.
> So it can't be the problem.
>
> https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/ags/X/ags_editor.c#n222
>
> Bests,
> Joël
>
>
> On Fri, May 5, 2017 at 6:09 PM, James Cowgill <jcowg...@debian.org> wrote:
>> Hi,
>>
>> On 05/05/17 13:36, Joël Krähemann wrote:
>>> Hi
>>>
>>> finally I got a stack-trace
>>>
>>> Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
>>> Core was generated by
>>> `/home/jkraehemann/gsequencer-0.8.0/.libs/ags_xorg_application_context_test'.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0  0x75e2af68 in IA__gtk_widget_show_all (widget=0x7280b790) at
>>> ./gtk/gtkwidget.c:3376
>>> 3376 ./gtk/gtkwidget.c: No such file or directory.
>>> (gdb)
>>> (gdb) bt
>>> #0  0x75e2af68 in IA__gtk_widget_show_all (widget=0x7280b790) at
>>> ./gtk/gtkwidget.c:3376
>>> #1  0x7677b6c8 in ags_machine_selector_popup_new
>>> (machine_selector=0x728104c0) at
>>> ags/X/editor/ags_machine_selector.c:569
>>> #2  0x766b60a4 in ags_automation_editor_init
>>> (automation_editor=0x7276f238) at ags/X/ags_automation_editor.c:222
>>> #3  0x75660948 in g_type_create_instance () from
>>> /usr/lib/mipsel-linux-gnu/libgobject-2.0.so.0
>>> Backtrace stopped: frame did not save the PC
>>
>> I ran this test in gdb on a real mips machine. When tracing through
>> ags_machine_selector_popup_new it seems that the "keys" variable is
>> never initialized and a garbage pointer is passed to gtk_widget_show_all.
>>
>> The variable is never initialized because this condition is false:
>> (AGS_MACHINE_SELECTOR_SHOW_SHIFT_PIANO & (machine_selector->flags)) != 0
>>
>> Thanks,
>> James
>>

Bug#861645: gsequencer FTBFS on mips/mipsel: FAIL: ags_xorg_application_context_test

[Joël Krähemann]

Hi

The flag was set. However it is not that beautiful.
So it can't be the problem.

https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/ags/X/ags_editor.c#n222

Bests,
Joël


On Fri, May 5, 2017 at 6:09 PM, James Cowgill <jcowg...@debian.org> wrote:
> Hi,
>
> On 05/05/17 13:36, Joël Krähemann wrote:
>> Hi
>>
>> finally I got a stack-trace
>>
>> Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
>> Core was generated by
>> `/home/jkraehemann/gsequencer-0.8.0/.libs/ags_xorg_application_context_test'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  0x75e2af68 in IA__gtk_widget_show_all (widget=0x7280b790) at
>> ./gtk/gtkwidget.c:3376
>> 3376 ./gtk/gtkwidget.c: No such file or directory.
>> (gdb)
>> (gdb) bt
>> #0  0x75e2af68 in IA__gtk_widget_show_all (widget=0x7280b790) at
>> ./gtk/gtkwidget.c:3376
>> #1  0x7677b6c8 in ags_machine_selector_popup_new
>> (machine_selector=0x728104c0) at
>> ags/X/editor/ags_machine_selector.c:569
>> #2  0x766b60a4 in ags_automation_editor_init
>> (automation_editor=0x7276f238) at ags/X/ags_automation_editor.c:222
>> #3  0x75660948 in g_type_create_instance () from
>> /usr/lib/mipsel-linux-gnu/libgobject-2.0.so.0
>> Backtrace stopped: frame did not save the PC
>
> I ran this test in gdb on a real mips machine. When tracing through
> ags_machine_selector_popup_new it seems that the "keys" variable is
> never initialized and a garbage pointer is passed to gtk_widget_show_all.
>
> The variable is never initialized because this condition is false:
> (AGS_MACHINE_SELECTOR_SHOW_SHIFT_PIANO & (machine_selector->flags)) != 0
>
> Thanks,
> James
>

Bug#861645: gsequencer FTBFS on mips/mipsel: FAIL: ags_xorg_application_context_test

[Joël Krähemann]

Hi

finally I got a stack-trace

Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
Core was generated by
`/home/jkraehemann/gsequencer-0.8.0/.libs/ags_xorg_application_context_test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x75e2af68 in IA__gtk_widget_show_all (widget=0x7280b790) at
./gtk/gtkwidget.c:3376
3376 ./gtk/gtkwidget.c: No such file or directory.
(gdb)
(gdb) bt
#0  0x75e2af68 in IA__gtk_widget_show_all (widget=0x7280b790) at
./gtk/gtkwidget.c:3376
#1  0x7677b6c8 in ags_machine_selector_popup_new
(machine_selector=0x728104c0) at
ags/X/editor/ags_machine_selector.c:569
#2  0x766b60a4 in ags_automation_editor_init
(automation_editor=0x7276f238) at ags/X/ags_automation_editor.c:222
#3  0x75660948 in g_type_create_instance () from
/usr/lib/mipsel-linux-gnu/libgobject-2.0.so.0
Backtrace stopped: frame did not save the PC

Bests,
Joël


On Wed, May 3, 2017 at 1:40 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> I just tried to run `make check` in a mipsel chroot on tty2.
>
> As running ./ags_xorg_application_context_test I get:
>
> Suite: AgsXorgApplicationContextTest
>   Test: test of AgsXorgApplicationContext doing dispose ...Unsupported
> ioctl: cmd=0x41785501
> Unsupported ioctl: cmd=0x41785501
> ** Message: Can't get the next card number: Success
> Unsupported ioctl: cmd=0x41785501
> Unsupported ioctl: cmd=0x41785501
> ** Message: Can't get the next card number: Success
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
>
> Might be some output was discarded. Escpecially
> Unsupported ioctl: cmd=...
>
> Bests,
> Joël
>
> On Tue, May 2, 2017 at 6:53 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
>> Hi
>>
>> I have experienced on some other architectures with
>> ags_xorg_application_context_test
>> the same problems. It was not evident to me if the problem was related
>> to Gtk+-2.0 or
>> xvfb-run since the stack-trace ended as doing gtk_widget_show(window);
>>
>> However other architectures just pass the test. Now, I'm going to set
>> up a VM to get a
>> meaningful stack-trace.
>>
>> Bests,
>> Joël
>>
>>
>> On Tue, May 2, 2017 at 10:05 AM, Adrian Bunk <b...@debian.org> wrote:
>>> Source: gsequencer
>>> Version: 0.8.0-1
>>> Severity: serious
>>>
>>> https://buildd.debian.org/status/package.php?p=gsequencer=sid
>>>
>>> ...
>>> make  check-TESTS
>>> make[3]: Entering directory '/«PKGBUILDDIR»'
>>> make[4]: Entering directory '/«PKGBUILDDIR»'
>>> PASS: ags_thread_test
>>> PASS: ags_audio_application_context_test
>>> PASS: ags_turtle_test
>>> PASS: ags_devout_test
>>> PASS: ags_channel_test
>>> PASS: ags_audio_test
>>> PASS: ags_audio_signal_test
>>> PASS: ags_recall_test
>>> PASS: ags_port_test
>>> PASS: ags_recycling_test
>>> PASS: ags_pattern_test
>>> PASS: ags_notation_test
>>> PASS: ags_automation_test
>>> PASS: ags_midi_buffer_util_test
>>> PASS: ags_midi_builder_test
>>> ./test-driver: line 107:  7386 Segmentation fault  "$@" > $log_file 2>&1
>>> FAIL: ags_xorg_application_context_test
>>> 
>>>gsequencer 0.8.0: ./test-suite.log
>>> 
>>>
>>> # TOTAL: 16
>>> # PASS:  15
>>> # SKIP:  0
>>> # XFAIL: 0
>>> # FAIL:  1
>>> # XPASS: 0
>>> # ERROR: 0
>>>
>>> .. contents:: :depth: 2
>>>
>>> FAIL: ags_xorg_application_context_test
>>> ===
>>>
>>>
>>>
>>>  CUnit - A unit testing framework for C - Version 2.1-3
>>>  http://cunit.sourceforge.net/
>>>
>>> ** Message: loading preferences from data[0x55df8774]
>>> ** Message: autosave-thread
>>> ** Message: false
>>> ** Message: simple-file
>>> ** Message: true
>>> ** Message: disable-feature
>>> ** Message: experimental
>>> ** Message: segmentation
>>> ** Message: 4/4
>>> ** Message: model
>>> ** Message: super-threaded
>>> ** Message: super-threaded-scope
>>> ** Message: channel
>>> ** Message: lock-global
>>> ** Message: ags-thread
>>> ** Message: lock-parent
>>> ** Message: ags-recycling-thread
>>> ** Message: backend
>>> ** Message: alsa
>>> ** Message: device
>>> ** 

Bug#861645: gsequencer FTBFS on mips/mipsel: FAIL: ags_xorg_application_context_test

[Joël Krähemann]

Hi

I just tried to run `make check` in a mipsel chroot on tty2.

As running ./ags_xorg_application_context_test I get:

Suite: AgsXorgApplicationContextTest
  Test: test of AgsXorgApplicationContext doing dispose ...Unsupported
ioctl: cmd=0x41785501
Unsupported ioctl: cmd=0x41785501
** Message: Can't get the next card number: Success
Unsupported ioctl: cmd=0x41785501
Unsupported ioctl: cmd=0x41785501
** Message: Can't get the next card number: Success
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

Might be some output was discarded. Escpecially
Unsupported ioctl: cmd=...

Bests,
Joël

On Tue, May 2, 2017 at 6:53 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> I have experienced on some other architectures with
> ags_xorg_application_context_test
> the same problems. It was not evident to me if the problem was related
> to Gtk+-2.0 or
> xvfb-run since the stack-trace ended as doing gtk_widget_show(window);
>
> However other architectures just pass the test. Now, I'm going to set
> up a VM to get a
> meaningful stack-trace.
>
> Bests,
> Joël
>
>
> On Tue, May 2, 2017 at 10:05 AM, Adrian Bunk <b...@debian.org> wrote:
>> Source: gsequencer
>> Version: 0.8.0-1
>> Severity: serious
>>
>> https://buildd.debian.org/status/package.php?p=gsequencer=sid
>>
>> ...
>> make  check-TESTS
>> make[3]: Entering directory '/«PKGBUILDDIR»'
>> make[4]: Entering directory '/«PKGBUILDDIR»'
>> PASS: ags_thread_test
>> PASS: ags_audio_application_context_test
>> PASS: ags_turtle_test
>> PASS: ags_devout_test
>> PASS: ags_channel_test
>> PASS: ags_audio_test
>> PASS: ags_audio_signal_test
>> PASS: ags_recall_test
>> PASS: ags_port_test
>> PASS: ags_recycling_test
>> PASS: ags_pattern_test
>> PASS: ags_notation_test
>> PASS: ags_automation_test
>> PASS: ags_midi_buffer_util_test
>> PASS: ags_midi_builder_test
>> ./test-driver: line 107:  7386 Segmentation fault  "$@" > $log_file 2>&1
>> FAIL: ags_xorg_application_context_test
>> 
>>gsequencer 0.8.0: ./test-suite.log
>> 
>>
>> # TOTAL: 16
>> # PASS:  15
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  1
>> # XPASS: 0
>> # ERROR: 0
>>
>> .. contents:: :depth: 2
>>
>> FAIL: ags_xorg_application_context_test
>> ===
>>
>>
>>
>>  CUnit - A unit testing framework for C - Version 2.1-3
>>  http://cunit.sourceforge.net/
>>
>> ** Message: loading preferences from data[0x55df8774]
>> ** Message: autosave-thread
>> ** Message: false
>> ** Message: simple-file
>> ** Message: true
>> ** Message: disable-feature
>> ** Message: experimental
>> ** Message: segmentation
>> ** Message: 4/4
>> ** Message: model
>> ** Message: super-threaded
>> ** Message: super-threaded-scope
>> ** Message: channel
>> ** Message: lock-global
>> ** Message: ags-thread
>> ** Message: lock-parent
>> ** Message: ags-recycling-thread
>> ** Message: backend
>> ** Message: alsa
>> ** Message: device
>> ** Message: hw:0,0
>> ** Message: samplerate
>> ** Message: 44100
>> ** Message: buffer-size
>> ** Message: 1024
>> ** Message: pcm-channels
>> ** Message: 2
>> ** Message: dsp-channels
>> ** Message: 2
>> ** Message: format
>> ** Message: 16
>> ** Message: backend
>> ** Message: alsa
>> ** Message: device
>> ** Message: hw:0,0
>> ** Message: samplerate
>> ** Message: 44100
>> ** Message: buffer-size
>> ** Message: 1024
>> ** Message: pcm-channels
>> ** Message: 2
>> ** Message: dsp-channels
>> ** Message: 2
>> ** Message: format
>> ** Message: 16
>> ** Message: auto-sense
>> ** Message: true
>>
>> Suite: AgsXorgApplicationContextTest
>>   Test: test of AgsXorgApplicationContext doing dispose ...** Message: Can't 
>> get the next card number: Success
>> ** Message: Can't get the next card number: Success
>> FAIL ags_xorg_application_context_test (exit status: 139)
>>
>> 
>> Testsuite summary for gsequencer 0.8.0
>> 
>> # TOTAL: 16
>> # PASS:  15
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  1
>> # XPASS: 0
>> # ERROR: 0
>> 
>> See ./test-suite.log
>> Please report to jkraehemann-gu...@users.alioth.debian.org
>> 
>> Makefile:9817: recipe for target 'test-suite.log' failed
>> make[4]: *** [test-suite.log] Error 1
>> ___
>> pkg-multimedia-maintainers mailing list
>> pkg-multimedia-maintain...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#861645: gsequencer FTBFS on mips/mipsel: FAIL: ags_xorg_application_context_test

[Joël Krähemann]

Hi

I have experienced on some other architectures with
ags_xorg_application_context_test
the same problems. It was not evident to me if the problem was related
to Gtk+-2.0 or
xvfb-run since the stack-trace ended as doing gtk_widget_show(window);

However other architectures just pass the test. Now, I'm going to set
up a VM to get a
meaningful stack-trace.

Bests,
Joël


On Tue, May 2, 2017 at 10:05 AM, Adrian Bunk  wrote:
> Source: gsequencer
> Version: 0.8.0-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=gsequencer=sid
>
> ...
> make  check-TESTS
> make[3]: Entering directory '/«PKGBUILDDIR»'
> make[4]: Entering directory '/«PKGBUILDDIR»'
> PASS: ags_thread_test
> PASS: ags_audio_application_context_test
> PASS: ags_turtle_test
> PASS: ags_devout_test
> PASS: ags_channel_test
> PASS: ags_audio_test
> PASS: ags_audio_signal_test
> PASS: ags_recall_test
> PASS: ags_port_test
> PASS: ags_recycling_test
> PASS: ags_pattern_test
> PASS: ags_notation_test
> PASS: ags_automation_test
> PASS: ags_midi_buffer_util_test
> PASS: ags_midi_builder_test
> ./test-driver: line 107:  7386 Segmentation fault  "$@" > $log_file 2>&1
> FAIL: ags_xorg_application_context_test
> 
>gsequencer 0.8.0: ./test-suite.log
> 
>
> # TOTAL: 16
> # PASS:  15
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> FAIL: ags_xorg_application_context_test
> ===
>
>
>
>  CUnit - A unit testing framework for C - Version 2.1-3
>  http://cunit.sourceforge.net/
>
> ** Message: loading preferences from data[0x55df8774]
> ** Message: autosave-thread
> ** Message: false
> ** Message: simple-file
> ** Message: true
> ** Message: disable-feature
> ** Message: experimental
> ** Message: segmentation
> ** Message: 4/4
> ** Message: model
> ** Message: super-threaded
> ** Message: super-threaded-scope
> ** Message: channel
> ** Message: lock-global
> ** Message: ags-thread
> ** Message: lock-parent
> ** Message: ags-recycling-thread
> ** Message: backend
> ** Message: alsa
> ** Message: device
> ** Message: hw:0,0
> ** Message: samplerate
> ** Message: 44100
> ** Message: buffer-size
> ** Message: 1024
> ** Message: pcm-channels
> ** Message: 2
> ** Message: dsp-channels
> ** Message: 2
> ** Message: format
> ** Message: 16
> ** Message: backend
> ** Message: alsa
> ** Message: device
> ** Message: hw:0,0
> ** Message: samplerate
> ** Message: 44100
> ** Message: buffer-size
> ** Message: 1024
> ** Message: pcm-channels
> ** Message: 2
> ** Message: dsp-channels
> ** Message: 2
> ** Message: format
> ** Message: 16
> ** Message: auto-sense
> ** Message: true
>
> Suite: AgsXorgApplicationContextTest
>   Test: test of AgsXorgApplicationContext doing dispose ...** Message: Can't 
> get the next card number: Success
> ** Message: Can't get the next card number: Success
> FAIL ags_xorg_application_context_test (exit status: 139)
>
> 
> Testsuite summary for gsequencer 0.8.0
> 
> # TOTAL: 16
> # PASS:  15
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to jkraehemann-gu...@users.alioth.debian.org
> 
> Makefile:9817: recipe for target 'test-suite.log' failed
> make[4]: *** [test-suite.log] Error 1
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#858285: gsequencer: New upstream version available 0.7.122.7

[Joël Krähemann]

Source: gsequencer
Severity: wishlist

Dear Maintainer,

The new package comes with a lot improvements. Thought the important ones are
provided by a patch. Maintenance would be just much easier as providing this
package.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#858283: gsequencer: GSequencer crashes as no soundcard configured

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

GSequencer allows configuration in place. As removing all soundcards and
adding certain machines it does SIGSEGV. This happens because of a NULL
pointer dereference.

GSequencer shall not crash under any circumstances.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857915: gsequencer: should link libraries using LIBADD instead of LDFLAGS

[Joël Krähemann]

Hi

I'm unsure about the issue. Could you provide an example?

cheers,
Joël


On Thu, Mar 16, 2017 at 11:43 AM, James Cowgill  wrote:
> Source: gsequencer
> Version: 0.7.122-2
> Severity: normal
>
> Hi,
>
> gsequencer incorrectly links libraries in Makefile.am using LDFLAGS
> instead of LIBADD. This causes the package to FTBFS when built with
> -Wl,--as-needed.
>
> This is the reason why Ubuntu has an old version of gsequencer. Ubuntu
> enables -Wl,--as-needed by default so they had to patch the source to
> get it to build. That patch hasn't been updated for sometime now so
> they've just kept the old version.
>
> Thanks,
> James
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#857948: Acknowledgement (gsequencer: missing mutex locks might crash the application)

[Joël Krähemann]

Hi

Just merged related patches to one file:
https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/patches/fix-missing-mutices.diff

bests,
Joël


On Thu, Mar 16, 2017 at 4:27 PM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Multimedia Maintainers 
> 
>
> If you wish to submit further information on this problem, please
> send it to 857...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 857948: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857948
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#857934: Acknowledgement (gsequencer: configuration in-place broken thread frequency)

[Joël Krähemann]

Hi

The patches were provided prior and are now merged to on patch file
because its related to each other:
https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/patches/fix-broken-thread-frequency.diff


On Thu, Mar 16, 2017 at 2:00 PM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Multimedia Maintainers 
> 
>
> If you wish to submit further information on this problem, please
> send it to 857...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 857934: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857934
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#857948: gsequencer: missing mutex locks might crash the application

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

Some mutex locks are missing. They protect common memory of threads.
The data-race may crash GSequencer.
It should add some mutexes.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857947: gsequencer: possible data-race as clearing buffer of soundcard

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

The soundcard output is affected by a data-race. While clearing the output 
buffer, a data
race is possible. Resulting in corrupted audio export or playback. The 
possibility of
an application crash exists.
The clearing of the buffer should occur as a task. In order to run asynchronous 
exclusively.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857937: Acknowledgement (gsequencer: memory leaks while g_timeout_add() function in GUI)

[Joël Krähemann]

Hi

Just added the needed patches:
https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/patches/fix-leak-while-g-timeout-function.diff

bests,
Joël


On Thu, Mar 16, 2017 at 2:15 PM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Multimedia Maintainers 
> 
>
> If you wish to submit further information on this problem, please
> send it to 857...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 857937: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857937
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#857931: Acknowledgement (gsequencer: AgsSynth possible division by zero by oscillator)

[Joël Krähemann]

Hi

Just provide the diff fixing the issue:
https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/patches/fix-possible-division-by-zero.diff

bests,
Joël


On Thu, Mar 16, 2017 at 1:51 PM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Multimedia Maintainers 
> 
>
> If you wish to submit further information on this problem, please
> send it to 857...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 857931: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857931
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#857933: Acknowledgement (gsequencer: The MIDI connection dialog is not provided by restoring AgsLv2Bridge)

[Joël Krähemann]

Hi

Just added the diff fixing missing midi connection dialog after restore:
https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/patches/fix-missing-midi-connection-dialog.diff

bests,
Joël


On Thu, Mar 16, 2017 at 1:57 PM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Multimedia Maintainers 
> 
>
> If you wish to submit further information on this problem, please
> send it to 857...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 857933: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857933
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#857935: Acknowledgement (gsequencer: SIGSEGV as doing NULL pointer dereference as restoring AgsFFPlayer)

[Joël Krähemann]

Hi all

Just provide the patch in alioth git repo:

https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/patches/fix-null-pointer-dereference.diff

bests,
Joël


On Thu, Mar 16, 2017 at 2:03 PM, Debian Bug Tracking System
 wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Multimedia Maintainers 
> 
>
> If you wish to submit further information on this problem, please
> send it to 857...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 857935: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857935
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#857936: gsequencer: duplicated flag AGS_MIDI_PARSER_EOT makes header useless

[Joël Krähemann]

Hi

just provided the patch

https://anonscm.debian.org/git/pkg-multimedia/gsequencer.git/tree/debian/patches/fix-duplicated-flag-definition.diff

bests,
Joël


On Thu, Mar 16, 2017 at 2:05 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Source: gsequencer
> Version: 0.7.122-2
> Severity: important
>
> Dear Maintainer,
>
> libags-audio.h is useless because there is a duplicated flag.
> It should not occure twice. The second AGS_MIDI_PARSER_EOT should
> be AGS_MIDI_BUILDER_EOT.
> Development with libags-audio.h is not possible.
> It should be possible to include it.
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
> to C.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>

Bug#857937: gsequencer: memory leaks while g_timeout_add() function in GUI

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

The missing free of a string and wrong free of a glist leaks memory.
This happens during g_timeout_add() function.
Since it polls it continuesly leaks memory.
The system shouldn't run out of memory.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857910: gsequencer: GObject::dispose() is not implemented

[Joël Krähemann]

Hi

Note some finalize() methods don't g_object_unref() all struct fields.
It has a strong relation to this bug.

Further GObject::dispose() requires Bug#857930 to be fixed.

Bests,
Joël


On Thu, Mar 16, 2017 at 1:25 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> Basically the changes from 0.7.122.6 to 0.7.122.7
> I have dedicated this release to memory-leaks.
> Note it includes some bug-fixes we should check
> if they are applicable to 0.7.122-2
>
> http://download.savannah.gnu.org/releases/gsequencer/stable
>
> Best,
> Joël
>
> On Thu, Mar 16, 2017 at 11:53 AM, Tino Mettler <t...@tikei.de> wrote:
>> Hi,
>>
>> please try to provide further details, like the exact upstream version
>> that contains the necessary change, or maybe a git commit from the
>> upstream repository that implements this.
>>
>> Regards,
>> Tino

Bug#857936: gsequencer: duplicated flag AGS_MIDI_PARSER_EOT makes header useless

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

libags-audio.h is useless because there is a duplicated flag.
It should not occure twice. The second AGS_MIDI_PARSER_EOT should
be AGS_MIDI_BUILDER_EOT.
Development with libags-audio.h is not possible.
It should be possible to include it.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857935: gsequencer: SIGSEGV as doing NULL pointer dereference as restoring AgsFFPlayer

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

The restore of AgsFFPlayer crashes as no Soundfont2 file is selected.
It causes SIGSEGV due to NULL pointer dereference.
GSequencer should not crash.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857934: gsequencer: configuration in-place broken thread frequency

[Joël Krähemann]

Source: gsequencer
Version: gsequencer
Severity: important

Dear Maintainer,

The configuration in place lacks updating thread frequencies. As modifying
buffer size or samplerate the refresh rate changes.
It shall update thread frequencies. Note it causes useless audio output.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857933: gsequencer: The MIDI connection dialog is not provided by restoring AgsLv2Bridge

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

After restore GSequencer doesn't provide the MIDI connection editor.
As adding the machine immediately the MIDI connection editor is there.
During restore there is a function call missing.
You expect the MIDI connection editor to present, always.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857931: gsequencer: AgsSynth possible division by zero by oscillator

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

The user can select a frequency of 0 what leads to a division by 0.
This causes a SIGSEGV and the application gets killed.
The application shouldn't crash at all.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857930: gsequencer: Wrong GParamSpec of mixed properties containing GObject and GList

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

Some mixed properties do use g_param_spec_object() instead of 
g_param_spec_pointer().
But g_value_set_object() doesn't work for GList.
The property doesn't return a value while calling g_object_get() or alike.
It should return a pointer to the copy of the GList.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#857910: gsequencer: GObject::dispose() is not implemented

[Joël Krähemann]

Hi

Basically the changes from 0.7.122.6 to 0.7.122.7
I have dedicated this release to memory-leaks.
Note it includes some bug-fixes we should check
if they are applicable to 0.7.122-2

http://download.savannah.gnu.org/releases/gsequencer/stable

Best,
Joël

On Thu, Mar 16, 2017 at 11:53 AM, Tino Mettler  wrote:
> Hi,
>
> please try to provide further details, like the exact upstream version
> that contains the necessary change, or maybe a git commit from the
> upstream repository that implements this.
>
> Regards,
> Tino

Bug#857910: gsequencer: GObject::dispose() is not implemented

[Joël Krähemann]

Hi

Upstream includes the wished changes. We could do a diff and strip
unwanted changes.

Bests,
Joël


On Thu, Mar 16, 2017 at 11:12 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Source: gsequencer
> Version: 0.7.122-2
> Severity: important
>
> Dear Maintainer,
>
> GObject::dispose() is not implemented. But it is necessary in order to 
> release circular dependencies properly.
> It causes to application to leak memory while playback.
> Only by program termination it is released.
>
> The application should not leak memory and it makes the usability of the 
> libraries questionable.
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
> to C.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>

Bug#857910: gsequencer: GObject::dispose() is not implemented

[Joël Krähemann]

Source: gsequencer
Version: 0.7.122-2
Severity: important

Dear Maintainer,

GObject::dispose() is not implemented. But it is necessary in order to release 
circular dependencies properly.
It causes to application to leak memory while playback.
Only by program termination it is released.

The application should not leak memory and it makes the usability of the 
libraries questionable.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/24 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#853936: unblock: gsequencer/0.7.122-2

[Joël Krähemann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gsequencer

There are some important bug-fixes available to gsequencer-0.7.122.
The fixes provide improvements to application stability. It might
look like there are many lines in the debdiff but the changes
are rather small und they use proven concepts.

(include/attach the debdiff against the package in testing)

unblock gsequencer/0.7.122-2

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0+ (SMP w/24 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gsequencer-0.7.122/debian/changelog 
gsequencer-0.7.122/debian/changelog
--- gsequencer-0.7.122/debian/changelog 2017-01-03 17:02:45.0 +0100
+++ gsequencer-0.7.122/debian/changelog 2017-02-01 11:14:14.0 +0100
@@ -1,3 +1,13 @@
+gsequencer (0.7.122-2) unstable; urgency=medium
+
+  [ Joël Krähemann ]
+  * Disabled ALSA on non-linux, and enabled OSS4 only on kFreeBSD
+(Closes: #852985)
+  * Backported patches (from upstream) to fix crasher bugs related to thread
+safety and memory corruption.
+
+ -- Joël Krähemann <jkraehemann-gu...@users.alioth.debian.org>  Wed, 01 Feb 
2017 11:14:14 +0100
+
 gsequencer (0.7.122-1) unstable; urgency=medium
 
   * New upstream version 0.7.122
diff -Nru gsequencer-0.7.122/debian/control gsequencer-0.7.122/debian/control
--- gsequencer-0.7.122/debian/control   2017-01-03 17:02:45.0 +0100
+++ gsequencer-0.7.122/debian/control   2017-01-31 10:31:42.0 +0100
@@ -20,8 +20,9 @@
  dssi-dev,
  lv2-dev,
  libgmp-dev,
- libasound2-dev|liboss4-salsa-dev,
- oss4-dev,
+ libasound2-dev [linux-any],
+ liboss4-salsa-dev [!linux-any],
+ oss4-dev [kfreebsd-any],
  libjack-dev,
  uuid-dev,
  docbook-xsl,
diff -Nru gsequencer-0.7.122/debian/patches/fix-clear-buffer-c.patch 
gsequencer-0.7.122/debian/patches/fix-clear-buffer-c.patch
--- gsequencer-0.7.122/debian/patches/fix-clear-buffer-c.patch  1970-01-01 
01:00:00.0 +0100
+++ gsequencer-0.7.122/debian/patches/fix-clear-buffer-c.patch  2017-02-01 
10:25:06.0 +0100
@@ -0,0 +1,391 @@
+Description: AgsClearBuffer fixes data-race causing distorted audio output
+ resulting in useless audio output. Introduced due to low-latency sync
+ strategy for ALSA audio output and alsa MIDI input. Might end in application
+ crash and is required by immediate sync strategy. This patch includes the
+ c-source file of the task clearing soundcard buffers in order you can do
+ additive mixing, during ordinary run context.
+Author: Joël Krähmann <jkraehem...@gmail.com>
+Applied-Upstream: 0.7.122.x, http://git.savannah.gnu.org/cgit/gsequencer.git
+Last-Update: 2017-01-31
+--- /dev/null
 b/ags/audio/task/ags_clear_buffer.c
+@@ -0,0 +1,379 @@
++/* GSequencer - Advanced GTK Sequencer
++ * Copyright (C) 2005-2015 Joël Krähemann
++ *
++ * This file is part of GSequencer.
++ *
++ * GSequencer is free software: you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published by
++ * the Free Software Foundation, either version 3 of the License, or
++ * (at your option) any later version.
++ *
++ * GSequencer is distributed in the hope that it will be useful,
++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++ * GNU General Public License for more details.
++ *
++ * You should have received a copy of the GNU General Public License
++ * along with GSequencer.  If not, see <http://www.gnu.org/licenses/>.
++ */
++
++#include 
++
++#include 
++#include 
++
++#include 
++#include 
++
++#include 
++#include 
++
++void ags_clear_buffer_class_init(AgsClearBufferClass *clear_buffer);
++void ags_clear_buffer_connectable_interface_init(AgsConnectableInterface 
*connectable);
++void ags_clear_buffer_init(AgsClearBuffer *clear_buffer);
++void ags_clear_buffer_set_property(GObject *gobject,
++   guint prop_id,
++   const GValue *value,
++   GParamSpec *param_spec);
++void ags_clear_buffer_get_property(GObject *gobject,
++   guint prop_id,
++   GValue *value,
++   GParamSpec *param_spec);
++void ags_clear_buffer_connect(AgsConnectable *connectable);
++void ags_clear_buffer_disconnect(AgsConnectable *connectable);
++void ags_clear_buffer_finalize(GObject *gobject);
++
++void ags_clear_buffer_launch(AgsTask *task);
++
++/**
++ * SECTION:ags_clear_buffer
++ * @short_description: switch buffer flag of device
++ * @title: AgsClearBuffer
++ * @section_id:
++ * @include: ags/audio/task/

Bug#852985: gsequencer: please do not build-depend on oss4-dev on Linux

[Joël Krähemann]

Hi

The patch looks fine. There should be no problem as passing this configure flag.
I even used gsequencer on linuxfromscratch.org based system without having OSS4
at all.

Note you can disable it for GNU/Hurd, as well. So JACK is the only output sink.

Bests,
Joël


On Sun, Jan 29, 2017 at 5:18 PM, Simon McVittie  wrote:
> Control: tags 852985 + patch
>
> On Sat, 28 Jan 2017 at 17:55:43 +, Simon McVittie wrote:
>> This package build-depends on oss4-dev, which is built by RC-buggy source
>> package oss4.
>
> I attach a possible patch.
>
> I don't know how to test gsequencer, so I am not intending to do a
> NMU for this bug.
>
> Regards,
> S

Bug#837606: general: system freeze

[Joël Krähemann]

Hi

I experienced the same as developing GSequencer probably a concurrency
issue. I had to fix it.
This can happen may be with unintialized mutices or conditional locks.

Bests,
Joël


On Tue, Sep 13, 2016 at 4:15 PM, Abou Al Montacir
 wrote:
> Control: reopen -1
>
>
> Sorry, I don't think that the best way to solve this issue is to close the
> bug.
>
> I personally encounter the very same issue when using epiphany browser with
> lindedIn. Imagine yourself sowing to your colleague something, you are
> enthusiast, and the unique  Linux user in the company, and proud to do it,
> but then it hangs. Awful, especially when they tackle you about all the says
> you did about an well known operating system whith blue screen!
>
> Now back to your request:
>
>
> On Tue, 13 Sep 2016 08:42:59 +1200 Ben Caradoc-Davies 
> wrote:
>> Rouven,
>>
>> you have provided very little information so it will be hard for anyone
>> to reproduce this problem.
>
> Yes, this is true, but not a reason to trash the bug report.
>
>>
>> - What causes the problem? Are you running any program in particular?
>
> The cause is that the system starts swapping on a laptop with 16GiB RAM and
> 32GiB swap on a 5200R/mn
> OK, my hard drive is slow but I don't see why it should hang the system.
>
>>
>> - What is your hardware? Desktop, laptop? Models? Video cards and
>> drivers can cause of hangs.
>
> A Dell pressario series 5500. Intel video card.
>
>>
>> - What do you mean by "freezes"? Can you ssh into the machine? Can you
>> suspend/resume? If you press the power button what happens?
>
> The only thing I can do is hit the power button for more than 4s. Otherwise,
> nothing works. I have a statical image, mouse can not move anymore, the
> clock stops updating on gnome panel and lid close dos not react any more.
> System does not enter sleep mode when I press power button, and even
> Verr/num led does not react anymore.
>
>>
>> - Does your keyboard work? Are you able to switch to a console with
>> Ctrl-Alt-F1? Back with Ctrl-F7?
>
> No, absolutely no.
>
>>
>> - Any indication of hardware problems such as failing storage or memory
>> errors? Overheating?
>
> No, it happens only when using the browser. It is clear that the browser
> have a bug but the system is not expected to freeze.
>
>>
>> - Wireless keyboard low battery or lost connection?
>
> No
>
>>
>> In any case, the Debian Bug Tracking System is not the most suitable
>> forum for general support unless you can determine specific steps to
>> reproduce this problem.
>
> Tried forums: https://lists.debian.org/debian-user/2015/10/msg01329.html
> However it is not a matter of discussion, it is a matter of tracking a real
> issue!
>
>>
>> Kind regards,
>
>
> Thanks for your effort
>
> --
> Abou Al Montacir
>

Bug#836328: gsequencer: FTBFS on non-Linux: ALSA too old (1.0.5 vs. 1.0.25)

[Joël Krähemann]

Hi

Upstream 0.7.64 contains now OSS support however alsa still required in order
to do DSSI and Lv2. I have replaced snd_midi_event_decode() with
ags_midi_buffer_util_decode().

Bests,
Joël


On Mon, Sep 5, 2016 at 10:35 AM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi
>
> I'm doing my best to port it. Most of the work has been fulfilled so far. I 
> just
> need to add a g_strv_length(), g_strv_contains() and snd_midi_event_decode()
> replacement.
>
> Since these functions aren't big it won't take too long. A bigger task would 
> be
> adding OSS output.
>
> Bests,
> Joël
>
>
>
> On Thu, Sep 1, 2016 at 7:15 PM, Aaron M. Ucko <a...@alum.mit.edu> wrote:
>> Source: gsequencer
>> Version: 0.7.62-1
>> Severity: important
>> Justification: fails to build from source
>>
>> Builds of gsequencer on kFreeBSD and the Hurd failed:
>>
>>   checking for LIBASOUND2... no
>>   configure: error: Package requirements (alsa >= 1.0.25) were not met:
>>
>>   Requested 'alsa >= 1.0.25' but version of alsa is 1.0.5
>>
>> Please either accommodate the (emulated, IIRC) version of ALSA
>> available there or version the build dependency on libasound2-dev
>> appropriately.
>>
>> Thanks!
>>
>> ___
>> pkg-multimedia-maintainers mailing list
>> pkg-multimedia-maintain...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#836328: gsequencer: FTBFS on non-Linux: ALSA too old (1.0.5 vs. 1.0.25)

[Joël Krähemann]

Hi

I'm doing my best to port it. Most of the work has been fulfilled so far. I just
need to add a g_strv_length(), g_strv_contains() and snd_midi_event_decode()
replacement.

Since these functions aren't big it won't take too long. A bigger task would be
adding OSS output.

Bests,
Joël



On Thu, Sep 1, 2016 at 7:15 PM, Aaron M. Ucko  wrote:
> Source: gsequencer
> Version: 0.7.62-1
> Severity: important
> Justification: fails to build from source
>
> Builds of gsequencer on kFreeBSD and the Hurd failed:
>
>   checking for LIBASOUND2... no
>   configure: error: Package requirements (alsa >= 1.0.25) were not met:
>
>   Requested 'alsa >= 1.0.25' but version of alsa is 1.0.5
>
> Please either accommodate the (emulated, IIRC) version of ALSA
> available there or version the build dependency on libasound2-dev
> appropriately.
>
> Thanks!
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#836327: gsequencer: FTBFS on mips and powerpc: ags_functional_audio_test segmentation fault

[Joël Krähemann]

Hi

Yesterday, I was providing an new tarball 0.7.63 making the tests
pass. ags_functional_audio_test.c needs your soundcard
but shouldn't crash if it's not available. Further there was an issue
with $(HOME)/.gsequencer/ags.conf having jack=enabled.
Since jack support is a work in progress it is not supported, yet. But
the new tarball should fix the NULL pointer access.

Bests,
Joël


On Thu, Sep 1, 2016 at 7:12 PM, Aaron M. Ucko  wrote:
> Source: gsequencer
> Version: 0.7.62-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The latest builds of gsequencer for mips and powerpc both failed
> because ags_functional_audio_test segfaulted:
>
> https://buildd.debian.org/status/fetch.php?pkg=gsequencer=mips=0.7.62-1=1472716604
> https://buildd.debian.org/status/fetch.php?pkg=gsequencer=powerpc=0.7.62-1=1472714618
>
> Could you please take a look?
>
> Thanks!
>

Bug#836326: gsequencer: FTBFS on i386: ags_channel_test segmentation fault

[Joël Krähemann]

Hi

Yesterday, I was providing a new tarball 0.7.63 fixing the unit tests.
They should all pass for now.

Bests,
Joël

On Thu, Sep 1, 2016 at 7:10 PM, Aaron M. Ucko  wrote:
> Source: gsequencer
> Version: 0.7.62-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The latest i386 build of gsequencer failed because ags_channel_test
> crashed.  Could you please take a look?
>
> Thanks!
>
>   PASS: ags_thread_test
>   PASS: ags_audio_test
>   ./test-driver: line 107:  9968 Segmentation fault  "$@" > $log_file 2>&1
>   FAIL: ags_channel_test
>   PASS: ags_recycling_test
>   PASS: ags_audio_signal_test
>   PASS: ags_recall_test
>   PASS: ags_pattern_test
>   PASS: ags_notation_test
>   PASS: ags_automation_test
>   PASS: ags_functional_audio_test
>   =
>  gsequencer 0.7.62: ./test-suite.log
>   =
>
>   # TOTAL: 10
>   # PASS:  9
>   # SKIP:  0
>   # XFAIL: 0
>   # FAIL:  1
>   # XPASS: 0
>   # ERROR: 0
>
>   .. contents:: :depth: 2
>
>   FAIL: ags_channel_test
>   ==
>
>
>
>CUnit - A unit testing framework for C - Version 2.1-3
>http://cunit.sourceforge.net/
>
>
>   Suite: AgsChannelTest
> Test: test of AgsChannel add recall ...passed
> Test: test of AgsChannel add recall container ...FAILED
>   1. ags/test/audio/ags_channel_test.c:131  - 
> g_list_find(channel->container, recall_container) != NULL
> Test: test of AgsChannel add recall id ...FAILED
>   1. ags/test/audio/ags_channel_test.c:148  - 
> g_list_find(channel->recall_id, recall_id) != NULL
> Test: test of AgsChannel add duplicate recall ...FAIL ags_channel_test 
> (exit status: 139)
>

Bug#807823: Patch to fix the issue

[Joël Krähemann]

Hi

I have just found the dead-lock. The issue should be fixed.

cheers,
Joël
Index: libinstpatch-1.0.0/libinstpatch/IpatchBase.c
===
--- libinstpatch-1.0.0.orig/libinstpatch/IpatchBase.c	2010-10-25 21:03:42.0 +0200
+++ libinstpatch-1.0.0/libinstpatch/IpatchBase.c	2015-12-18 10:01:02.384180605 +0100
@@ -231,7 +231,7 @@
   IPATCH_ITEM_RLOCK (base);
   file = base->file;
   if (file) g_object_ref (file);
-  IPATCH_ITEM_RLOCK (base);
+  IPATCH_ITEM_RUNLOCK (base);
 
   return (file);
 }

Bug#807823: test case to reconstruct the situation

[Joël Krähemann]

Hi

I'm just doing a test-case:
https://github.com/gsequencer/gsequencer/blob/0.6.0/src/ags/test/ags_libinstpatch_test.c

cheers,
Joël

Bug#807823: dead-lock as calling functions from different threads

[Joël Krähemann]

Package: libinstpatch-1.0-0
Version: 1.0.0-4
Severity: important
Tags: upstream



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libinstpatch-1.0-0 depends on:
ii  libc6  2.19-22
ii  libglib2.0-0   2.46.2-1
ii  libsndfile11.0.25-10
ii  multiarch-support  2.21-3

libinstpatch-1.0-0 recommends no packages.

libinstpatch-1.0-0 suggests no packages.

-- no debconf information

Hi, I just reported it to upstream please see:

http://sourceforge.net/p/swami/mailman/message/34691038/

Here's the relevant part of the stack-trace:

Thread 35 (Thread 0x7f9e23323700 (LWP 29857)):
#0  0x7f9e494747fc in __lll_lock_wait () at
.../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x7f9e494704d4 in _L_lock_986 () at
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7f9e49470336 in __GI___pthread_mutex_lock
(mutex=0x7f9e17374570) at ../nptl/pthread_mutex_lock.c:114
#3  0x7f9e4c226ba1 in g_static_rec_mutex_lock
(mutex=0x7f9e17607dc0) at
/build/glib2.0-ocmJ1Y/glib2.0-2.46.2/./glib/deprecated/gthread-deprecated.c:708
#4  0x7f9e4c7925d4 in ipatch_container_get_children () at
/usr/lib/x86_64-linux-gnu/libinstpatch-1.0.so.0
#5  0x0047e9a3 in ags_ipatch_level_select (playable=, nth_level=, sublevel_name=0x7f9e1804bbe0 "Bowed
Glass", error=0x7f9e23321798) at src/ags/audio/file/ags_ipatch.c:567

Bug#807823: detailed stack-trace

[Joël Krähemann]

Hi, here you have a stack-trace with debugging symbols.

One thread opens the file an other one reads of it.

Thread 35 (Thread 0x7f45cc8a0700 (LWP 9062)):
#0  0x7f45f29bc7fc in __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x7f45f29b84d4 in _L_lock_986 () at
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7f45f29b8336 in __GI___pthread_mutex_lock
(mutex=0x7f45c1412f90) at ../nptl/pthread_mutex_lock.c:114
#3  0x7f45f576eba1 in g_static_rec_mutex_lock
(mutex=0x7f45c1427f30) at
/build/glib2.0-ocmJ1Y/glib2.0-2.46.2/./glib/deprecated/gthread-deprecated.c:708
#4  0x7f45f5cda5d4 in ipatch_container_get_children
(container=0x7f45c0386500 [IpatchSF2], type=13378144) at
IpatchContainer.c:123
#5  0x0047e9a3 in ags_ipatch_level_select (playable=, nth_level=, sublevel_name=0x7f45c4054770
"Acoustic Bass", error=0x7f45cc89e8f8) at
src/ags/audio/file/ags_ipatch.c:569
#6  0x004fcf2f in ags_ffplayer_preset_changed_callback
(preset=0x4b9c420 [GtkComboBoxText], ffplayer=0x4b91460 [AgsFFPlayer])
at src/ags/X/machine/ags_ffplayer_callbacks.c:197

cheers,
Joël

Bug#807823: calling functions

[Joël Krähemann]

Here's an overview what I'm doing ...

Thread A:

/* open file */
ipatch_file_identify_open();
ipatch_sf2_reader_new();
ipatch_sf2_reader_load();
ipatch_convert_object_to_type();
ipatch_container_get_children();

/* select preset */
ipatch_container_get_children();
ipatch_sf2_preset_get_name();

/* select instrument */
ipatch_sf2_preset_get_zones();
ipatch_sf2_zone_get_link_item();

/* read instrument names */
ipatch_sf2_preset_get_zones();
ipatch_sf2_zone_get_link_item();

/* read all samples related to preset and instrument */
ipatch_sf2_preset_get_zones();
ipatch_sf2_zone_get_link_item();
g_object_get(G_OBJECT(sample),
   "sample-size\0", frames,
   "loop-start\0", loop_start,
   "loop-end\0", loop_end,
   NULL);
ipatch_sf2_find_sample();
ipatch_sample_read_transform();

Thread B:

/* select preset */
ipatch_container_get_children();
ipatch_sf2_preset_get_name();

/* select instrument */
ipatch_sf2_preset_get_zones();
ipatch_sf2_zone_get_link_item();

/* read instrument names */
ipatch_sf2_preset_get_zones();
ipatch_sf2_zone_get_link_item();

/* read all samples related to preset and instrument */
ipatch_sf2_preset_get_zones();
ipatch_sf2_zone_get_link_item();
g_object_get(G_OBJECT(sample),
   "sample-size\0", frames,
   "loop-start\0", loop_start,
   "loop-end\0", loop_end,
   NULL);
ipatch_sf2_find_sample();
ipatch_sample_read_transform();

Bests,
Joël