Bug#829417: dosemu: *** stack smashing detected ***: /usr/bin/xdosemu terminated

2017-07-01 Thread Steven Gawroriski 
Hello,

At the top of debian/rules addding the following:

DEB_BUILD_MAINT_OPTIONS=hardening=-all
export DEB_BUILD_MAINT_OPTIONS

stops crashes from occurring by disabling the protection mechanisms
provided by GCC. This does not truly fix the issue because dosemu
itself should be modified to handle cases where GCC's protection
mechanisms are used.

Bug#829417: dosemu: *** stack smashing detected ***: /usr/bin/xdosemu terminated

2017-06-12 Thread Steven Gawroriski 
On x86_64 running Stretch, I also get this when trying to run unzip32
from DJGPP which is at the following URL:

http://www.delorie.com/pub/djgpp/current/unzip32.exe

Changing the CPU type to "full" allows the command to run however it
quickly crashes with:

ERROR: Fault in dosemu code, in_dpmi=1
ERROR: cpu exception in dosemu code outside of DPMI client!
trapno: 0x0e  errorcode: 0x0004  cr2: 0xa028601d
eip: 0x564da024d887  esp: 0x7ffe84229960  eflags: 0x00010246
cs: 0x0033  ds: 0x  es: 0x  ss: 0x002b
ERROR: Please report the contents of ~/.dosemu/boot.log at
http://sourceforge.net/tracker/?atid=457447_id=49784=browse
It would be even more helpful if would recompile DOSEMU and reproduce
this bug with "debug on" in compiletime-settings.
Page fault: read instruction to linear address: 0xa028601d
CPU was in user mode
Exception was caused by non-available page

I have additionally attached the boot.log file.
CONF: config variable parser_version_3 set
CONF: config variable c_system set
CONF: Parsing built-in dosemu.conf file.
CONF: config variable version_3_style_used set
CONF: Parsing built-in global.conf file.
CONF: config variable version_3_style_used unset
CONF: config variable version_3_style_used set
CONF: opened include file /etc/dosemu/dosemu.conf
CONF: closed include file /etc/dosemu/dosemu.conf
CONF: mapping driver = 'auto'
debug flags: -a+cw
CONF: Disabling use of pentium timer
CONF: dosbanner on
CONF: timer freq=18, update=54925
CONF: CPU set to 586
CONF: JIT CPUEMU set to 4 for 586
CONF: 8192k bytes EMS memory
CONF: EMS-frame = 0xe400
CONF: DPMI-Server on (0x5000)
CONF: DPMI base addr = 0x
CONF: PM DOS API Translator on
CONF: No DJGPP NULL deref checks: off
CONF: 8192k bytes XMS memory
CONF: dosemu not running on console
CONF: time mode = 'bios'
SER: directory /var/lock namestub LCK.. binary No
MOUSE: no device specified, type 0 using internaldriver: yes, emulate3buttons: no baudrate: 0
CONF: Keyboard-layout keyb-user
CONF:  Warning: floppy /dev/fd0 not accessible, disabled
CONF: fastfloppy = 1
CONF: IPX support off
CONF(LPT0) f: (null)   c: lpr -l  t: 20  port: 0
CONF(LPT1) f: (null)   c: lpr -l -P lpt2  t: 20  port: 0
CONF: not allowing speaker port access
CONF: Packet Driver enabled.
device: /home/steven/.dosemu/drives/c type 4 h: -1  s: -1   t: -1 drive C:
device: /home/steven/.dosemu/drives/d type 4 h: -1  s: -1   t: -1 drive D:
CONF: cdrom MSCD0001 on /dev/cdrom
CONF: config variable c_system unset
Linux kernel 4.9.0; CPU speed is 213400 Hz
CPU-EMU speed is 2134 MHz
CONF: mostly running as USER: uid=1000 (cached 1000) gid=1000 (cached 1000)
DBG_FD already set
DOSEMU-1.4.0.8 is coming up on Linux version 4.9.0-3-amd64 #1 SMP Debian 4.9.30-1 (2017-06-04) x86_64
Compiled with GCC version 6.3.0 -m64
WARN: vm86plus service not available in your kernel
WARN: using CPU emulation for vm86()
CONF: reserving 640Kb at 0x0 for 'd' (Base DOS memory (first 640K))
CONF: reserving 48Kb at 0xF4000 for 'r' (Dosemu reserved area)
CONF: reserving 128Kb at 0xA for 'v' (Video memory)
PKT: Cannot open raw sockets: Operation not permitted
WARN: using non-zero memory base address 0x10f000.
WARN: You can use the better-tested zero based setup using
WARN: sysctl -w vm.mmap_min_addr=0
WARN: as root, or by changing the vm.mmap_min_addr setting in
WARN: /etc/sysctl.conf or a file in /etc/sysctl.d/ to 0.
CONF: reserving 8256Kb at 0x10 for 'x' (Extended memory (HMA+XMS))
Registering HWRAM, type=e base=0x4197c000 size=0x40
CONF: reserving 4096Kb at 0x4197C000 for 'e' (VGAEMU LFB)
CONF: reserving 12Kb at 0xC for 'V' (VGAEMU Video BIOS)
SERIAL $Id$
CONF: detected layout is "us"
CONF: detected alternate layout: us
CONF: reserving 16Kb at 0xE4000 for 'E' (EMS page frame)
CONF: reserving 16Kb at 0xE8000 for 'E' (EMS page frame)
CONF: reserving 16Kb at 0xEC000 for 'E' (EMS page frame)
CONF: reserving 16Kb at 0xF for 'E' (EMS page frame)
CONF: reserving 132Kb at 0xC3000 for 'U' (Upper Memory Block (UMB, XMS 3.0))
TIME: using 9154 usec for updating ALRM timer
=== ENTER CPU-EMU ===

*	Fault out of DOSEMU code, cs:eip=33:564da028bd16, cr2=11cf, fault_cnt=1
*	Fault out of DOSEMU code, cs:eip=33:564da02884ec, cr2=11db, fault_cnt=1
*	Fault out of DOSEMU code, cs:eip=33:564da02884ec, cr2=11db, fault_cnt=1
*	Fault out of DOSEMU code, cs:eip=33:564da02884ec, cr2=11db, fault_cnt=1
*	Fault out of DOSEMU code, cs:eip=33:564da02884ec, cr2=11db, fault_cnt=1
*	Fault out of DOSEMU code, cs:eip=33:564da028bd16, cr2=11cf, fault_cnt=1
ERROR: Fault in dosemu code, in_dpmi=1
ERROR: cpu exception in dosemu code outside of DPMI client!
trapno: 0x0e  errorcode: 0x0004  cr2: 0xa028601d
eip: 0x564da024d887  esp: 0x7ffe84229960  eflags: 0x00010246
cs: 0x0033  ds: 0x  es: 0x  ss: 0x002b
ERROR: Please report the contents of ~/.dosemu/boot.log at
http://sourceforge.net/tracker/?atid=457447_id=49784=browse
It would be even more helpful if would recompile DOSEMU and

Bug#844617: g++-mingw-w64: C++ linking fails with cannot find -latomic.

2016-11-17 Thread Steven Gawroriski 
On Thu, 17 Nov 2016 21:04:49 +0100
Stephen Kitt <sk...@debian.org> wrote:

> Hi Steven,
> 
> On Thu, 17 Nov 2016 11:20:59 -0500, Steven Gawroriski
> <ste...@multiphasicapps.net> wrote:
> > During the linking stage of even the most simplest source code
> > (just a main function), the C++ linking fails because it cannot
> > find `-latomic`. This effectively makes the C++ compiler useless
> > because it cannot link any binaries.  
> 
> Could you try on another architecture? I can link C++ programs on all
> the architectures I have easy access to (amd64, i386, armhf, arm64)
> and the resulting programs run correctly on Windows.
> 
> Thanks,
> 
> Stephen

Hello,

I do not have another architecture running sid. However, it appears
that the compiler is configured with `--disable-libatomic`, if this
makes a difference.

Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/6.1-win32/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../../src/configure --build=powerpc-linux-gnu
--prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man'
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir='/usr/lib/powerpc-linux-gnu'
--libexecdir='/usr/lib/powerpc-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --prefix=/usr --enable-shared
--enable-static --disable-multilib --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib
--enable-libstdcxx-time=yes --with-tune=generic
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++
--enable-lto --with-plugin-ld --enable-threads=win32
--program-suffix=-win32 --program-prefix=i686-w64-mingw32-
--target=i686-w64-mingw32 --with-as=/usr/bin/i686-w64-mingw32-as
--with-ld=/usr/bin/i686-w64-mingw32-ld --disable-libatomic
Thread model: win32
gcc version 6.1.1 20160815 (GCC)

Thanks.


pgpa7pE3kYErU.pgp
Description: OpenPGP digital signature

Bug#844617: g++-mingw-w64: C++ linking fails with cannot find -latomic.

2016-11-17 Thread Steven Gawroriski 
Package: g++-mingw-w64
Version: 6.1.1-12+19.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

During the linking stage of even the most simplest source code (just a
main function), the C++ linking fails because it cannot find `-latomic`.
This effectively makes the C++ compiler useless because it cannot link
any binaries.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 4.4.27.161027.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages g++-mingw-w64 depends on:
ii  g++-mingw-w64-i6866.1.1-12+19.1
ii  g++-mingw-w64-x86-64  6.1.1-12+19.1

g++-mingw-w64 recommends no packages.

g++-mingw-w64 suggests no packages.

-- no debconf information

Bug#841853: inkscape: Mouse cursor is a white outline on PowerPC

2016-11-07 Thread Steven Gawroriski 
On Mon, 7 Nov 2016 16:28:13 +
Mattia Rizzolo  wrote:

> ouch, that must be awful!

It seems to be fine now. Last Saturday (November 5th) downloading the
source package completed rather quickly (10 seconds perhaps?).

> Great!
> I also noticed that they committed the patch already in both trunk and
> 0.92.x (that, who knows, they might even release some day)
> 
> I'll see about uploading an updated debian package with this too.

That would be cool.

Thanks.

Bug#841853: inkscape: Mouse cursor is a white outline on PowerPC

2016-11-06 Thread Steven Gawroriski 
On Sun, 6 Nov 2016 15:00:39 +
Mattia Rizzolo  wrote:

> Thanks for doing it.
> 
> Thanks for the patch!

Thanks.

> Though, I'd like to ask you to foward this patch upstream.  It's
> enough to open a MR against
> https://code.launchpad.net/~inkscape.dev/inkscape/trunk for it.
> 
> Could you do it?
> 

Since today my internet connection is unusually and abysmally slow,
checking out of the Inkscape repository was essentially moving at
dial-up speeds.

So instead I have submitted a bug report with the attached patch, along
with a reference to this bug.

 * https://bugs.launchpad.net/inkscape/+bug/1639611

> ↑↑↑ be aware of these 4 trailing whitespaces, some people don't like
> them.

I removed the trailing whitespace from the patch before uploading it to
their bug tracker. The spaces were made by auto-indent.

Bug#841853: inkscape: Mouse cursor is a white outline on PowerPC

2016-11-05 Thread Steven Gawroriski 
Taking a look at this myself. The issue is related to cursors and is
either an issue in:

 * Inkscape
 * GDK
 * XRender

Since the star cursor in Inkscape shows the color to be drawn,
including alpha. Using the color `FFDD8833` (which is kind of a tan
color) appears on the star cursor itself as a sky blue. The actual
color being shown on the cursor is `#3388DD` (or ARGB #FF3388DD).
Changing in Inkscape the `FF` (which should be red, but is alpha) makes
the blue in the cursor a bit transparent.

I am definitely certain that the issue is in Inkscape only. Other
programs such as GIMP and anything else do not have any cursor issues
at all from what I can tell. If GDK or XRender were at fault, likely
more than just a single program would be broken.

The only place in the Inkscape code which loads cursors is
`sp_cursor_pixbuf_from_xpm`. The `RGBA` struct has a static cast to a
`guint32` which bitshifts in values accordingly. However part of the
function `sp_cursor_pixbuf_from_xpm` contains the following:

guint32 *pixmap_buffer = new guint32[width * height];

However, before returning this buffer is `reinterpret_cast`ed such as
the following:

return
gdk_pixbuf_new_from_data(reinterpret_cast<guchar*>(pixmap_buffer),
GDK_COLORSPACE_RGB, TRUE, 8, width, height, width *
sizeof(guint32), free_cursor_data, NULL);

Looking at the documentation for `gdk_pixbuf_new_from_data`, the data
for this call is just specified as _Image data in 8-bit/sample packed
format_.

I wrote the attached patch which essentially byte swaps the value
before this function returns. The cursors are drawn correctly and
Inkscape can now be used much more easily. If a contributor agreement
is required then I would accept giving away my copyright for the code
contained in this patch.

Description: Swap before return sp_cursor_pixbuf_from_xpm on big endian.
 This byte swaps before the return in sp_cursor_pixbuf_from_xpm on big
 endian systems so that the cursor is made visible on these systems.
Author: Steven Gawroriski <ste...@multiphasicapps.net>

---

Origin: other
Bug-Debian: https://bugs.debian.org/841853

--- inkscape-0.91.orig/src/sp-cursor.cpp
+++ inkscape-0.91/src/sp-cursor.cpp
@@ -106,6 +106,14 @@ GdkPixbuf *sp_cursor_pixbuf_from_xpm(gch
 pixmap_buffer[y * width + x] = (it == colorMap.end()) ? 0u : it->second;
 }
 }
+
+#if G_BYTE_ORDER == G_BIG_ENDIAN
+for (int i = 0, n = width * height; i < n; i++)
+{
+guint32 v = pixmap_buffer[i];
+pixmap_buffer[i] = ((v & 0xFF) << 24) | (((v >> 8) & 0xFF) << 16) | (((v >> 16) & 0xFF) << 8) | ((v >> 24) & 0xFF);
+}
+#endif
 
 return gdk_pixbuf_new_from_data(reinterpret_cast<guchar*>(pixmap_buffer), GDK_COLORSPACE_RGB, TRUE, 8, width, height, width * sizeof(guint32), free_cursor_data, NULL);
 }

Bug#841853: inkscape: Mouse cursor is a white outline on PowerPC

2016-10-23 Thread Steven Gawroriski 
Package: inkscape
Version: 0.91-11
Severity: important

Dear Maintainer,

On PowerPC, cursors in Inkscape are just a white outline. On other
systems there should be black in the center or at least in some
situations a black outline around the white outline. The parts that
should be black are invisible.

This makes Inkscape very difficult to use because on very bright
colors, the mouse cursor is near-impossible or impossible to see.

Since this system is big endian, it is likely that the channels are
being read incorrectly (FF00 or similar becomes 00FF).



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Foreign Architectures: i386

Kernel: Linux 4.8.3.161021.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-3+b1
ii  libatk1.0-02.22.0-1
ii  libatkmm-1.6-1v5   2.24.2-2
ii  libc6  2.24-3
ii  libcairo2  1.14.6-1+b1
ii  libcairomm-1.0-1v5 1.12.0-1+b1
ii  libcdr-0.1-1   0.1.3-3
ii  libexif12  0.6.21-2
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1
ii  libgc1c2   1:7.4.2-8
ii  libgcc11:6.2.0-6
ii  libgdk-pixbuf2.0-0 2.36.0-1
ii  libglib2.0-0   2.50.1-1
ii  libglibmm-2.4-1v5  2.50.0-1
ii  libgomp1   6.2.0-6
ii  libgsl22.2.1+dfsg-1
ii  libgtk2.0-02.24.31-1
ii  libgtkmm-2.4-1v5   1:2.24.5-1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.5.0-1
ii  liblcms2-2 2.7-1
ii  libmagick++-6.q16-5v5  8:6.8.9.9-7.2+b1
ii  libmagickcore-6.q16-2  8:6.8.9.9-7.2+b1
ii  libmagickwand-6.q16-2  8:6.8.9.9-7.2+b1
ii  libpango-1.0-0 1.40.3-2
ii  libpangocairo-1.0-01.40.3-2
ii  libpangoft2-1.0-0  1.40.3-2
ii  libpangomm-1.4-1v5 2.40.1-3
ii  libpng16-161.6.25-2
ii  libpoppler-glib8   0.44.0-3
ii  libpoppler61   0.44.0-3
ii  libpopt0   1.16-10
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.2.0-6
ii  libvisio-0.1-1 0.1.5-4
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.3-1
ii  libxml22.9.4+dfsg1-2
ii  libxslt1.1 1.1.29-1
pn  python:any 
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages inkscape recommends:
ii  aspell0.60.7~20110707-3+b1
ii  fig2dev [transfig]1:3.2.6-3
ii  imagemagick   8:6.8.9.9-7.2+b1
ii  libimage-magick-perl  8:6.8.9.9-7.2
pn  libwmf-bin
ii  python-lxml   3.6.4-1
ii  python-numpy  1:1.11.2-1
ii  transfig  1:3.2.6-3

Versions of packages inkscape suggests:
pn  dia | dia-gnome  
pn  libsvg-perl  
pn  libxml-xql-perl  
pn  pstoedit 
ii  python-uniconvertor  1.1.5-3
ii  ruby 1:2.3.0+4

-- no debconf information

Bug#841229: openjdk-8-jre-jamvm: OutOfMemoryError in ConcurrentHashMap

2016-10-18 Thread Steven Gawroriski 
Package: openjdk-8-jre-jamvm
Version: 8u102-b14.1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Using JamVM causes the following exception to be thrown running the most
simplest programs from "Hello World" to the Java compiler:

Error: A JNI error has occurred, please check your installation and try
again java.lang.OutOfMemoryError
at
java.util.concurrent.ConcurrentHashMap.initTable(ConcurrentHashMap.java:2233)
at
java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1017)
at
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
at
sun.util.locale.LocaleObjectCache.put(LocaleObjectCache.java:87) at
sun.util.locale.BaseLocale.createInstance(BaseLocale.java:69) at
java.util.Locale.createConstant(Locale.java:709) at
java.util.Locale.(Locale.java:490) at
java.lang.String.toLowerCase(String.java:2670) at
java.net.URL.(URL.java:385) at java.net.URL.(URL.java:310)
at java.net.URL.(URL.java:333)
at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:272)
at sun.misc.Launcher.getFileURL(Launcher.java:484)
at
sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:194) at
sun.misc.Launcher$ExtClassLoader.(Launcher.java:164) at
sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:148) at
sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:142) at
java.security.AccessController.doPrivileged(Native Method) at
sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:141)
at sun.misc.Launcher.(Launcher.java:71)
at sun.misc.Launcher.(Launcher.java:57)
at
java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1451) at
java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1436) at
sun.launcher.LauncherHelper.(LauncherHelper.java:92)

HotSpot Zero (which is far slower) is not affected by this issue.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: powerpc (ppc)

Kernel: Linux 4.7.0-1-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjdk-8-jre-jamvm depends on:
ii  libc6   2.24-3
ii  openjdk-8-jre-headless  8u102-b14.1-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

openjdk-8-jre-jamvm recommends no packages.

openjdk-8-jre-jamvm suggests no packages.

-- no debconf information