Bug#764353: libhdf4: FTBFS on s390x and ppc64el: test failures
Source: libhdf4 Severity: serious Version: 4.2.10-2 libhdf4 FTBFS in the (newly enabled) test suite on s390x and ppc64el. On s390x, the test setup program crashes: https://buildd.debian.org/status/fetch.php?pkg=libhdf4arch=s390xver=4.2.10-2stamp=1412545742 === HDF Library Fortran Interface Tests Setup === *** Error in `/«PKGBUILDDIR»/HDF4.2.10/hdf/test/.libs/lt-fortestF': free(): invalid next size (fast): 0xafeb3fd0 *** Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x3FFFD066C57 #1 0x3FFFD0673B5 #2 0x39721F3 #3 0x3FFFCE3340C #4 0x3FFFCE34A0D #5 0x3FFFCE7D491 #6 0x3FFFCE83EFD #7 0x3FFFCE84ED3 #8 0x3FFFD2A38B1 #9 0x3FFFD2A41FD #10 0x80007DB5 in MAIN__ at fortestF.f:? Aborted On ppc64el, The testsuite went in a loop, so the log is too big to be sent (12GB). Aurelien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763821: [pkg-fgfs-crew] Bug#763821: FlightGear can't load any data and gets Segmentation fault
The underlying bug has now been fixed in unstable, and this fix should reach testing in 5-10 days; you can either use the environment variable workaround until then, or install the fixed libopenscenegraph100 from unstable ( https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tracking_literal_testing_literal_with_some_packages_from_literal_unstable_literal ). Are the unable to load messages gone as well? If so, I agree that this bug should be closed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763821: [pkg-fgfs-crew] Bug#763821: FlightGear can't load any data and gets Segmentation fault
Please install the debugging symbols and run a backtrace, as follows: $ sudo apt-get install libsimgearcore3.0.0-dbg libsimgearscene3.0.0-dbg gdb $ gdb fgfs (gdb) run [wait for crash] (gdb) thread apply all bt full Is it possible that you're running out of memory? Given that you have TerraSync enabled (which is higher resolution than the built-in scenery), expect to use around 2.5GB. The 'not found' errors suggest an incomplete Terrasync download (terrain but not the objects that go with it), but I don't know if they're related to the crash; does $ fgfs --disable-terrasync load successfully? If it does, try turning Terrasync back on via the tick box under File Scenery Download and waiting for it to finish (~200MB, Information shows status), then closing and restarting FlightGear. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763821: [pkg-fgfs-crew] Bug#763821: Bug#763821: FlightGear can't load any data and gets Segmentation fault
The backtrace points to an exit handler, which suggests that FlightGear was already closing itself due to some other error (probably the unloadable objects) before it crashed. Yes, after disable the terrasync, it would not crash anymore. [...] The most importantly, the objects still cannot be loaded. What exactly do you mean by this: is it giving failed to load errors (but not crashing) with Terrasync off, and if so which files? Did you try turning Terrasync back on via the tick box under File Scenery Download and waiting for it to finish (~200MB, Information shows status), then closing and restarting FlightGear. and if so, did it help? (Note that FlightGear remembers the Terrasync setting between runs, so after a --disable-terrasync run it stays off until you explicitly turn it on again.) Do the files named in the unable to load messages exist (under ~/.fgfs/TerraSync, e.g. ls ~/.fgfs/TerraSync/Models/Power)? it looks to be related to the bug [#763816] in libopenscenegraph100: Probably not, but to make sure try: $ OSG_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu fgfs --enable-terrasync -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763285: flightgear: failed to create GraphicsContext
Control: retitle -1 flightgear: failed to create GraphicsContext getDefaultWindow: failed to create GraphicsContext getDefaultWindow: failed to create GraphicsContext I think this is your real problem: FlightGear is failing to create its main window and hence closing itself. (The segfault appears to be the shutdown code then trying to clean up something that was never actually initialized: while technically a bug, it probably isn't the reason you can't use FlightGear.) To check whether this is a problem further down the graphics stack, try: glxgears (from package mesa-utils, should display animated gears; try both stable and testing/unstable versions) osgwidgetstyled (from package openscenegraph, should display rectangles; you need 3.2.0~rc1-5.1+b1, currently in testing (but may not stay there long, so do this now), to match your existing libopenscenegraph99) There is a new libopenscenegraph100, and a rebuild of simgear/flightgear against it, currently in unstable, but that may not be safe to install in a mostly-wheezy system, as its dependencies will replace your JPEG library (libjpeg62, https://release.debian.org/transitions/html/jpeg-turbo.html). Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Where did that come from? Stable is 3.2, unstable/testing is 3.16. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763285: [pkg-fgfs-crew] Bug#763285: flightgear: unable to start (segfault)
Can you post a gdb backtrace with debugging symbols installed, as follows: $ sudo apt-get install libsimgearcore3.0.0-dbg libsimgearscene3.0.0-dbg $ gdb fgfs (gdb) run [wait for crash] (gdb) thread apply all bt full Is it possible that you're running out of memory? FlightGear typically uses 1-2.5GB. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740898: chkrootkit: falsely flags Suckit rootkit when systemd or upstart is /sbin/init
Control: merge -1 748048 Still exists in current sid, and also triggered by Upstart: https://bugs.launchpad.net/ubuntu/+source/chkrootkit/+bug/454566 There is a proposed patch there, but I haven't tested it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760077: Bug #760077 (etc.): flightgear-data-aircrafts: SenecaII issues
Control: forwarded 760077 private-email Control: forwarded 760698 private-email Control: forwarded 760083 private-email Control: forwarded 760082 private-email Control: forwarded 760081 private-email Control: tags 760077 patch I have forwarded these to the aircraft's author (not including their address here as FlightGear spam-protects email addresses and Debian doesn't). Sorry for the delay, he was fixing the crash bug that delayed 3.2. As most of these are essentially new development, it may make more sense for you to work directly with upstream in the future: either email the aircraft's author, or if you can't find an address for them, use https://code.google.com/p/flightgear-bugs/ or http://sourceforge.net/p/flightgear/mailman/flightgear-devel/ . For more information, see http://wiki.flightgear.org/Portal:Developer/Aircraft -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762092: sha...sum man pages refer to nonexistent 'sha...sum invocation' info pages
Package: coreutils Version: 8.23-2 Severity: minor Control: tags -1 patch The man page of sha512sum states that more documentation can be found at info coreutils 'sha512sum invocation', but this info node does not exist; the correct name is 'sha2 utilities'. At least sha256sum, and I suspect all four sizes, are also affected. (See also #760861.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751450: wine multiarch warning is missing a step
Control: reopen -1 Control: tags -1 patch Fixed in wine-development is not fixed in wine; the same patch should work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757819: qemu-debootstrap can't handle Pre-Depends
Control: retitle -1 qemu-debootstrap can't handle Pre-Depends As the error message suggests, this is due to debootstrap trying to unpack something before configuring its Pre-Depends. #487908 was the same problem on the native architecture, which was fixed by the code at scripts/sid:174-185 and functions:1284-1288. A possible hint as to why this fix doesn't work here is this part of the log, suggesting they aren't being added to the dpkg database before calling dpkg --predep-package (which needs to know what we want to install to be of any use): Setting up init (1.21) ... Processing triggers for libc-bin (2.19-11) ... dpkg: warning: package not in database at line 98: apt [...same for everything else in the base-but-not-required list...] dpkg: warning: found unknown packages; this might mean the available database is outdated, and needs to be updated through a frontend method Selecting previously unselected package apt. (Reading database ... 6884 files and directories currently installed.) Preparing to unpack .../archives/apt_1.0.8_s390x.deb ... Unpacking apt (1.0.8) ... I don't know why this isn't happening, or whether it might cause any other problems. An (untested) way to fix this bug without needing it would be to put the unpack and configure steps in a single retry loop (instead of the two separate retry loops at scripts/sid:187-197), allowing Pre-Depends to be dealt with the same way as ordinary Depends, i.e. run through the list repeatedly until everything gets done. Priority:required packages and their dependencies can't trigger this because they are installed with --force-depends; this now (since init 1.21) includes systemd, so it no longer triggers this bug, but a plain (not buildd) debootstrap of s390x still does, as s390-tools Depends on gawk which Pre-Depends on libgmp10. (A workaround would be to simply --exclude s390-tools, as its description suggests it isn't needed in a qemu-user environment.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756133: unable to reproduce: qemu-user-static: fails to create rootfs with qemu-debootstrap for s390x
I can't reproduce this in either Ubuntu 14.04 (qemu 2.0.0+dfsg-2ubuntu1.3) or Debian sid (qemu 2.1+dfsg-4, itself a chroot under Ubuntu): creating a buildd chroot succeeds, a plain chroot fails but with what looks like #757819 rather than this. Is anyone else still able to reproduce this, or has it been fixed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761603: libhdf4: wrong endianness on s390x/mips
Package: libhdf4-0 Version: 4.2.10~1exp1 Control: tags -1 patch (from debian/patches/hdfi.h ) --- a/HDF4/hdf/src/hconv.h +++ b/HDF4/hdf/src/hconv.h @@ -59,7 +59,7 @@ /* CONSTANT DEFINITIONS */ /*/ /* Generally Big-Endian machines */ -#if !defined(INTEL86) !defined(MIPSEL) !defined(DEC_ALPHA) !defined(I860) !defined(SUN386) !(defined(__ia64) !(defined(hpux) || defined(__hpux))) !defined(__x86_64__) +#if !defined(INTEL86) !defined(MIPSEL) !defined(DEC_ALPHA) !defined(I860) !defined(SUN386) !(defined(__ia64) !(defined(hpux) || defined(__hpux))) !defined(__x86_64__) (defined(__powerpc__) !defined(__LITTLE_ENDIAN__)) !defined(__aarch64__) !defined(__ARM_EABI__) That treats anything that isn't powerpc as little-endian, which is wrong for s390x and mips. The result of this appears to be that while the data itself gets put the right way round, the array size metadata doesn't: # t100x100 is the test file from http://sources.debian.net/src/libhdf4/4.2.10-1%7Eexp1/hdf/util/testfiles/fp2hdf/t100x100/ amd64$ hdfimport t100x100 -o test_amd64.hdf qemu-s390x$ hdfimport t100x100 -o test_s390x.hdf $ cmp test_s390x.hdf test_amd64.hdf -l 41095 144 0 41098 0 144 41192 144 0 41195 0 144 41293 0 102 41294 0 310 41295 310 0 41296 102 0 42044 62 63 amd64$ hdiff test_amd64.hdf test_s390x.hdf Comparison not supported DataSet has rank 2, dimensions [ 100 100 ] DataSet has rank 2, dimensions [ 1677721600 1677721600 ] # 1677721600 = 100 24 qemu-s390x$ hdiff test_amd64.hdf test_s390x.hdf Comparison not supported DataSet has rank 2, dimensions [ 1677721600 1677721600 ] DataSet has rank 2, dimensions [ 100 100 ] qemu-s390x$ hdp dumpsds test_s390x.hdf File name: test_s390x.hdf Variable Name = DataSet Index = 0 Type= 32-bit floating point Ref. = 2 Compression method = NONE Rank = 2 Number of attributes = 1 Dim0: Name=fakeDim0 Size = 100 Scale Type = 32-bit floating point Number of attributes = 0 Dim1: Name=fakeDim1 Size = 100 Scale Type = 32-bit floating point Number of attributes = 0 Attr0: Name = valid_range Type = 32-bit floating point Count= 2 Value = 0.00 100.00 Data : [...large array...] amd64$ hdp dumpsds test_s390x.hdf File name: test_s390x.hdf Variable Name = DataSet Index = 0 Type= 32-bit floating point Ref. = 2 Compression method = NONE Rank = 2 Number of attributes = 1 Dim0: Name=fakeDim0 Size = 1677721600 Scale Type = 32-bit floating point Number of attributes = 0 Dim1: Name=fakeDim1 Size = 1677721600 Scale Type = 32-bit floating point Number of attributes = 0 Attr0: Name = valid_range Type = 32-bit floating point Count= 2 Value = 0.00 0.00 Data : in sdsdumpfull: space allocation for buf failed. Terminated! If you want to keep this (weird, and fragile in that it silently treats anything it doesn't recognise as big-endian) form use +#if !defined(INTEL86) !defined(MIPSEL) !defined(DEC_ALPHA) !defined(I860) !defined(SUN386) !(defined(__ia64) !(defined(hpux) || defined(__hpux))) !defined(__x86_64__) !(defined(__powerpc__) defined(__LITTLE_ENDIAN__)) !defined(__aarch64__) !defined(__ARM_EABI__) Fortunately, nothing outside libhdf4 uses this header (according to codesearch.debian.net), so nothing else should need recompiling. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761203: simgear: Broken endianness detection
Package: simgear
Version: 3.2.0~git20140719+4a9125-2
Control: found -1 3.0.0-4
Control: tags -1 patch
simgear/nasal/naref.h uses a list of architectures to determine
endianness, which is wrong on mipsel (it assumes __mips is always
big-endian) and fails on anything it doesn't recognise (such as arm64:
https://launchpadlibrarian.net/183053167/buildlog_ubuntu-utopic-arm64.simgear_3.0.0-4_FAILEDTOBUILD.txt.gz
).
The attached replaces this with the gcc __BYTE_ORDER__ macro.
Description: Use __BYTE_ORDER__ instead of arch list, and add test
Fixes wrong endianness on mipsel and FTBFS on arm64
https://launchpadlibrarian.net/183053167/buildlog_ubuntu-utopic-arm64.simgear_3.0.0-4_FAILEDTOBUILD.txt.gz
Author: Rebecca Palmer
diff --git a/simgear/nasal/cppbind/nasal_num_test.cxx b/simgear/nasal/cppbind/nasal_num_test.cxx
index e1e7dd0..d99034b 100644
--- a/simgear/nasal/cppbind/nasal_num_test.cxx
+++ b/simgear/nasal/cppbind/nasal_num_test.cxx
@@ -83,6 +83,12 @@ static void runNumTests( double (TestContext::*test_double)(const std::string),
BOOST_CHECK_EQUAL((c.*test_int)(0x755), 0x755);
BOOST_CHECK_EQUAL((c.*test_int)(0x055), 0x55);
BOOST_CHECK_EQUAL((c.*test_int)(-0x155), -0x155);
+
+ BOOST_CHECK_CLOSE((c.*test_double)(2.00953656983160),
+ 2.00953656983160, 1e-5);
+ /* this value has bit pattern 0x40007fff6789L,
+ * so will look like a pointer if the endianness is set wrong
+ * (see naref.h, data.h)*/
}
BOOST_AUTO_TEST_CASE( parse_num )
diff --git a/simgear/nasal/naref.h b/simgear/nasal/naref.h
index 66ddedb..2ff9d57 100644
--- a/simgear/nasal/naref.h
+++ b/simgear/nasal/naref.h
@@ -1,28 +1,31 @@
#ifndef _NAREF_H
#define _NAREF_H
-/* Rather than play elaborate and complicated games with
- * platform-dependent endianness headers, just detect the platforms we
- * support. This list is simpler and smaller, yet still quite
- * complete. */
#if (defined(__x86_64) defined(__linux__)) || defined(__sparcv9) || \
defined(__powerpc64__)
-/* Win64 and Irix should work with this too, but have not been
- * tested */
+/* NASAL_NAN64 mode requires 64 bit pointers that only use the
+ * lower 48 bits; Win64 and Irix should work with this too, but
+ * have not been tested */
# define NASAL_NAN64
+#elif defined(__BYTE_ORDER__)
+/* GCC and Clang define these (as a builtin, while
+* __LITTLE_ENDIAN__ requires a header), MSVC doesn't */
+# if __BYTE_ORDER__==__ORDER_LITTLE_ENDIAN__
+# define NASAL_LE
+# elif __BYTE_ORDER__==__ORDER_BIG_ENDIAN__
+# define NASAL_BE
+# else
+# error Unrecognized endianness
+# endif
#elif defined(_M_IX86) || defined(i386) || defined(__x86_64) || \
defined(__ia64__) || defined(_M_IA64) || defined(__ARMEL__) || \
- defined(_M_X64) || defined(__alpha__) || \
- (defined(__sh__) defined(__LITTLE_ENDIAN__))
+ defined(_M_X64) || defined(_M_ARM)
# define NASAL_LE
-#elif defined(__sparc) || defined(__ppc__) || defined(__PPC) || \
- defined (__powerpc__) || defined (__powerpc64__) || defined (__alpha__) || \
- defined(__mips) || defined(__ARMEB__) || \
- defined(__hppa__) || defined(__s390__) || defined(__s390x__) || \
- (defined(__sh__) !defined(__LITTLE_ENDIAN__))
+#elif defined(__sparc) || defined(__ARMEB__) || \
+ defined(__hppa__) || defined(__s390__) || defined(__s390x__)
# define NASAL_BE
#else
-# error Unrecognized CPU architecture
+# error Unknown endianness
#endif
typedef union {
Bug#742421: libhdf4: that fix won't quite work on Debian
(from debian/patches/hdfi.h at https://launchpad.net/ubuntu/+source/libhdf4/4.2r10-0ubuntu1 ) --- a/HDF4/hdf/src/hconv.h +++ b/HDF4/hdf/src/hconv.h @@ -59,7 +59,7 @@ /* CONSTANT DEFINITIONS */ /*/ /* Generally Big-Endian machines */ -#if !defined(INTEL86) !defined(MIPSEL) !defined(DEC_ALPHA) !defined(I860) !defined(SUN386) !(defined(__ia64) !(defined(hpux) || defined(__hpux))) !defined(__x86_64__) +#if !defined(INTEL86) !defined(MIPSEL) !defined(DEC_ALPHA) !defined(I860) !defined(SUN386) !(defined(__ia64) !(defined(hpux) || defined(__hpux))) !defined(__x86_64__) (defined(__powerpc__) !defined(__LITTLE_ENDIAN__)) !defined(__aarch64__) !defined(__ARM_EABI__) That treats anything that isn't powerpc as little-endian, which happens to be true in Ubuntu, but isn't in Debian. If you want to keep this (weird, and fragile in that it silently treats anything it doesn't recognise as big-endian) form use +#if !defined(INTEL86) !defined(MIPSEL) !defined(DEC_ALPHA) !defined(I860) !defined(SUN386) !(defined(__ia64) !(defined(hpux) || defined(__hpux))) !defined(__x86_64__) !(defined(__powerpc__) defined(__LITTLE_ENDIAN__)) !defined(__aarch64__) !defined(__ARM_EABI__) but if it were my package I'd probably do something similar to #761203 ( https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=naref_endianness.patch;att=1;bug=761203 ) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757395: fixed upstream beignet: CMakeLists.txt prohibits copying
Control: tag -1 fixed-upstream Upstream have removed this notice from master (without comment beyond fix a license issue: http://lists.freedesktop.org/archives/beignet/2014-August/003710.html ), but not stable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750380: Fwd: could you submit your patch to beignet mail list
See https://01.org/community/signed-process for what this means. From: Gong, Zhigang zhigang.g...@intel.com Hi Alexander, Could you submit the patch to beignet mail list at beig...@lists.freedesktop.orgmailto:beig...@lists.freedesktop.org with your signed-off signature. Thus we can merge it into beignet upstream tree. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757919: simgear: FTBFS on big-endian archs
Package: simgear
Version: 3.2.0~git20140719+4a9125-1
Severity: serious
Control: tags -1 patch
https://buildd.debian.org/status/package.php?p=simgearsuite=experimental
Untested fix attached.
Description: Actually enable the big-endian fallback
Author: Rebecca Palmer rebecca_pal...@zoho.com
WORDS_BIGENDIAN isn't actually defined anywhere, causing md5.c to
default to little-endian, and fail tests if this is wrong:
https://buildd.debian.org/status/logs.php?pkg=simgearver=3.2.0~git20140719%2B4a9125-1suite=experimental
Forwarded: can't be as it stands (probably breaks Windows/MSVC)
--- simgear-3.2.0~git20140719+4a9125.orig/simgear/package/md5.c
+++ simgear-3.2.0~git20140719+4a9125/simgear/package/md5.c
@@ -158,7 +158,7 @@ SG_MD5Transform(u_int32_t state[4], cons
{
u_int32_t a, b, c, d, in[MD5_BLOCK_LENGTH / 4];
-#ifndef WORDS_BIGENDIAN
+#if __BYTE_ORDER__==__ORDER_LITTLE_ENDIAN__
memcpy(in, block, sizeof(in));
#else
for (a = 0; a MD5_BLOCK_LENGTH / 4; a++) {
@@ -247,4 +247,4 @@ SG_MD5Transform(u_int32_t state[4], cons
state[1] += b;
state[2] += c;
state[3] += d;
-}
\ No newline at end of file
+}
Bug#745363: beignet: No way to check whether the hardware is present
Sorry, missed a new-in-0.9 fail point; corrected version attached.
(Testing hint: by default, the GPU isn't visible from inside a chroot)
Upgrading to 0.9 does fix #745767 (duplicate listing in
/etc/OpenCL/vendors), and comments there suggest it fixes LP#1350773
(llvm 3.5 incompatibility); #740695/LP#1255323 (broken header path)
appears to already be fixed in 0.8.
Description: If no device, return CL_DEVICE_NOT_FOUND instead of exiting
If no Intel GPU is present, beignet currently exits on
clGetDeviceIDs. This patch instead returns CL_DEVICE_NOT_FOUND,
allowing the calling application to decide what to do
(e.g. try a different platform).
Author: Rebecca Palmer rebecca_pal...@zoho.com
Bug-Debian: https://bugs.debian.org/745363
Forwarded: no
--- beignet-0.9.3git.orig/src/cl_api.c
+++ beignet-0.9.3git/src/cl_api.c
@@ -170,6 +170,7 @@ cl_check_device_type(cl_device_type devi
static cl_int
cl_device_id_is_ok(const cl_device_id device)
{
+ if(UNLIKELY(device == NULL)) return CL_FALSE;
return device != cl_get_gt_device() ? CL_FALSE : CL_TRUE;
}
--- beignet-0.9.3git.orig/src/cl_device_data.h
+++ beignet-0.9.3git/src/cl_device_data.h
@@ -20,6 +20,8 @@
#ifndef __CL_DEVICE_DATA_H__
#define __CL_DEVICE_DATA_H__
+#define INVALID_CHIP_ID -1 //returned by intel_get_device_id if no device found
+
#define PCI_CHIP_GM45_GM0x2A42
#define PCI_CHIP_IGD_E_G0x2E02
#define PCI_CHIP_Q45_G 0x2E12
--- beignet-0.9.3git.orig/src/intel/intel_driver.c
+++ beignet-0.9.3git/src/intel/intel_driver.c
@@ -193,7 +193,7 @@ intel_driver_init(intel_driver_t *driver
#endif /* EMULATE_GEN */
}
-static void
+static cl_int
intel_driver_open(intel_driver_t *intel, cl_context_prop props)
{
int cardi;
@@ -203,7 +203,7 @@ intel_driver_open(intel_driver_t *intel,
props-gl_type != CL_GL_GLX_DISPLAY
props-gl_type != CL_GL_EGL_DISPLAY) {
fprintf(stderr, Unsupported gl share type %d.\n, props-gl_type);
-exit(-1);
+return CL_INVALID_OPERATION;
}
intel-x11_display = XOpenDisplay(NULL);
@@ -239,7 +239,7 @@ intel_driver_open(intel_driver_t *intel,
if(!intel_driver_is_active(intel)) {
fprintf(stderr, Device open failed, aborting...\n);
-exit(-1);
+return CL_DEVICE_NOT_FOUND;
}
#ifdef HAS_EGL
@@ -247,6 +247,7 @@ intel_driver_open(intel_driver_t *intel,
assert(props-egl_display);
}
#endif
+ return CL_SUCCESS;
}
static void
@@ -399,7 +400,7 @@ intel_get_device_id(void)
driver = intel_driver_new();
assert(driver != NULL);
- intel_driver_open(driver, NULL);
+ if(UNLIKELY(intel_driver_open(driver, NULL) != CL_SUCCESS)) return
INVALID_CHIP_ID;
intel_device_id = driver-device_id;
intel_driver_context_destroy(driver);
intel_driver_close(driver);
@@ -426,7 +427,7 @@ cl_intel_driver_new(cl_context_prop prop
{
intel_driver_t *driver = NULL;
TRY_ALLOC_NO_ERR (driver, intel_driver_new());
- intel_driver_open(driver, props);
+ if(UNLIKELY(intel_driver_open(driver, props) != CL_SUCCESS)) goto error;
exit:
return driver;
error:
--- beignet-0.9.3git.orig/src/intel/intel_gpgpu.c
+++ beignet-0.9.3git/src/intel/intel_gpgpu.c
@@ -1500,6 +1500,4 @@ intel_set_gpgpu_callbacks(int device_id)
intel_gpgpu_get_scratch_index = intel_gpgpu_get_scratch_index_gen7;
intel_gpgpu_post_action = intel_gpgpu_post_action_gen7;
}
- else
-assert(0);
}
Bug#745363: beignet: No way to check whether the hardware is present
(Sorry for delay: n...@bugs.debian.org doesn't go to the bug submitter, you need nnn-submit...@bugs.debian.org for that.) I recently acquired Intel GPU hardware: 0.8 works as well with this patch as without it (i.e. badly but that's an unrelated problem: https://bugs.launchpad.net/ubuntu/+source/beignet/+bug/1354086 ). The patch fails to apply to 0.9x; I will attempt to fix this and submit it upstream. Also, there's a copyright problem in CMakeLists.txt: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757395 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757178: [pkg-fgfs-crew] Bug#757178: fgrun: does not export environment variables to fgfs
Control: tags -1 upstream patch
Control: forwarded -1 flightgear-de...@lists.sourceforge.net
The above patch doesn't compile, but this one does, and appears to work.
I have reported this upstream.
--- a/src/run_posix.cxx
+++ b/src/run_posix.cxx
@@ -124,9 +124,16 @@ Wizard::run_fgfs( const std::string args )
buf[0] = 0;
prefs.get( Fl_Preferences::Name(env-var-%d, i),
buf, , buflen-1 );
- char* s = strdup( buf );
- putenv( s );
-free( s );
+char* equals = strchr(buf, '=');
+if (equals == NULL) { /* environment variable name without
a value;
+ unsetenv(buf);
+}
+else { /* value exists */
+ *equals = '\0'; /* replace '=' with a new terminator; the
value f
+ setenv(/* name: */ buf,
+ /* value: */ equals + 1,
+ /* overwrite: */ 1);
+}
}
vectorstring argv;
argv.push_back( arg0 );
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#393650: Firefox randomly crashing
I'm now running Ubuntu 6.10, and still having this problem, though they think it's GTK rather than Firefox: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/78809 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406298: No warning of write failure
Package: nautilus-cd-burner Version: 2.8.7-3 My CD writer (Optorite CW5205) is old and often fails to complete a write; in Windows this aborts the process with an error message (Track following error or Focus or tracking error), but in Debian Sarge the process appears to succeed, and the problem only becomes apparent when one tries to read the disc. This occurs with both .iso images and the CD/DVD Creator. This may be related to GNOME bug http://bugzilla.gnome.org/show_bug.cgi?id=340822 (no warning after a *read* failure). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393650: Firefox randomly hanging-now with trace (sorry)
Sorry about the previous non-traces, I forgot to run bt (hadn't used gdb before
this)...here is one with a trace (from a hang while using the scroll bar (traced
before forcing it closed) and subsequent refusal to restart). {...} are my
comments.
Also included is an APT error I keep getting while trying to build an unstripped
Firefox; is there a problem at the server end?
At the end is a previous series of refusals to start, from which I forgot to
obtain proper traces, but am concerned about the appearance of js when I have
JavaScript turned off (though it could well be something else, my home page
https://webmail.ox.ac.uk doesn't contain any JavaScript anyway).
[EMAIL PROTECTED]:~$ DEB_BUILD_OPTIONS=nostrip fakeroot apt-get -b source
mozilla-firefox
Reading Package Lists... Done
Building Dependency Tree... Done
Need to get 40.6MB of source archives.
Get:1 http://security.debian.org stable/updates/main mozilla-firefox
1.0.4-2sarge11 (dsc) [1003B]
{long pause with progress indicator at 100% of next file}
Get:2 http://security.debian.org stable/updates/main mozilla-firefox
1.0.4-2sarge11 (tar) [40.2MB]
Get:3 http://security.debian.org stable/updates/main mozilla-firefox
1.0.4-2sarge11 (diff) [419kB]
Err http://security.debian.org stable/updates/main mozilla-firefox
1.0.4-2sarge11 (diff)
Error reading from server Remote end closed connection [IP: 212.211.132.250
80]
Fetched 40.2MB in 7m30s (89.4kB/s)
Failed to fetch
http://security.debian.org/pool/updates/main/m/mozilla-firefox/mozilla-firefox_1.0.4-2sarge11.diff.gz
Error reading from server Remote end closed connection [IP: 212.211.132.250 80]
E: Failed to fetch some archives.
[EMAIL PROTECTED]:~$ firefox -g GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-linux...(no debugging symbols found)
Using host libthread_db library /lib/tls/libthread_db.so.1.
(gdb) set pagination 0
(gdb) run
Starting program: /usr/lib/mozilla-firefox/firefox-bin -a firefox
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 1086687264 (LWP 3579)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread 1097067440 (LWP 3582)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread 1109760944 (LWP 3583)]
[New Thread 1118149552 (LWP 3584)]
[New Thread 1128266672 (LWP 3585)]
(no debugging symbols found)
(no debugging symbols found)
[New Thread 1136966576 (LWP 3586)]
(no debugging symbols found)
[New Thread 1145551792 (LWP 3587)]
[Thread 1145551792 (LWP 3587) exited]
(no debugging symbols found)
[New Thread 1145551792 (LWP 3588)]
(no debugging symbols found)
[Thread 1136966576 (LWP 3586) exited]
Program received signal SIGSEGV, Segmentation
Bug#393650: Firefox refusing to start again
The original repeated refusal to start crash reappeared today.
The first run in the following trace worked normally, the subsequent ones failed
to start (Firefox window did not appear). Text in {} is my comments.
[EMAIL PROTECTED]:~$ firefox -g
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-linux...(no debugging symbols found)
Using host libthread_db library /lib/tls/libthread_db.so.1.
(gdb) run
Starting program: /usr/lib/mozilla-firefox/firefox-bin -a firefox
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 1086683168 (LWP 3549)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type return to continue, or q return to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type return to continue, or q return to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread 1097059248 (LWP 3552)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type return to continue, or q return to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread 1109744560 (LWP 3553)]
[New Thread 1118133168 (LWP 3554)]
(no debugging symbols found)
(no debugging symbols found)
[New Thread 1127287728 (LWP 3555)]
(no debugging symbols found)
[New Thread 1135868848 (LWP 3556)]
[Thread 1135868848 (LWP 3556) exited]
(no debugging symbols found)
[Thread 1127287728 (LWP 3555) exited]
[Thread 1109744560 (LWP 3553) exited]
[New Thread 1109744560 (LWP 3557)]
[New Thread 1127287728 (LWP 3558)]
[Thread 1109744560 (LWP 3557) exited]
[Thread 1127287728 (LWP 3558) exited]
[New Thread 1127287728 (LWP 3559)]
[New Thread 1109744560 (LWP 3560)]
[Thread 1127287728 (LWP 3559) exited]
[Thread 1109744560 (LWP 3560) exited]
[New Thread 1109744560 (LWP 3561)]
[New Thread 1127287728 (LWP 3562)]
[Thread 1109744560 (LWP 3561) exited]
[Thread 1097059248 (LWP 3552) exited]
[Thread 1127287728 (LWP 3562) exited]
[Thread 1118133168 (LWP 3554) exited]
Program exited normally.
(gdb) run
Starting program: /usr/lib/mozilla-firefox/firefox-bin -a firefox
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 1086683168 (LWP 3563)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type return to continue, or q return to quit---
(no debugging symbols found)
(no
Bug#393650: Firefox randomly closing, then refusing to restart with segfault
Package: mozilla-firefox
Version: 1.0.4-2sarge11
Recently (since about last week's xfree86 security update), Mozilla Firefox has
sometimes (every day or two) either refused to start or randomly closed itself
(without any error message) and refused to restart. Once it has appeared the
problem persists through multiple start attempts, until cleared by either
rebooting the system or reinstalling Firefox (apt-get install mozilla-firefox
mozilla-firefox-gnome-support --reinstall).
On a failed start from the Applications menu or desktop icon, the menu closes
normally but nothing else visible happens. On a failed start from a terminal,
the error message can be either just Segmentation fault or /usr/bin/firefox:
line 349: 3610 Segmentation fault DISPLAY=${CMDLINE_DISPLAY}
${MOZ_PROGRAM} -remote 'ping()' /dev/null 21
Segmentation fault.
While it is possible that the cause is outside Firefox (I run a commercial
on-access antivirus which doesn't officially support Debian
(http://www.sophos.com/support/knowledgebase/article/4377.html) and get a lot of
INIT: No inittab file found hangs on shutdown/reboot, though /etc/inittab is
in fact present), nothing else seems to be crashing like this.
I am running Sarge, with all security updates, dual boot with Windows 98 on an
Intel Celeron 500MHz, 256MB RAM, RTL8139 Ethernet card connected to college
network. I know how to program, but mostly do games/simulations and have never
worked on anything as security-critical as a web browser.
When I tried to obtain a stack trace, I got the following:
[EMAIL PROTECTED]:~$ firefox %u
/usr/bin/firefox: line 349: 3610 Segmentation fault
DISPLAY=${CMDLINE_DISPLAY} ${MOZ_PROGRAM} -remote 'ping()' /dev/null 21
Segmentation fault
[EMAIL PROTECTED]:~$ gdb firefox
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-linux.../usr/bin/firefox: not in executable
format: File format not recognized
(gdb) run
Starting program:
No executable file specified.
Use the file or exec-file command.
(gdb) file /usr/lib/mozilla-firefox/firefox-bin
Reading symbols from /usr/lib/mozilla-firefox/firefox-bin...(no debugging
symbols found)...done.
Using host libthread_db library /lib/tls/libthread_db.so.1.
(gdb) run
Starting program: /usr/lib/mozilla-firefox/firefox-bin
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 1086683104 (LWP 3622)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type return to continue, or q return to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type return to continue, or q return to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread 1097059248 (LWP 3625)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type return to continue, or q return to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols
Bug#393650: Under debugger, Firefox now randomly hanging with broken pipe instead
Please try again with firefox -g (which will launch gdb for you) I did this, and haven't yet seen the original symptoms again, but have seen another crash: after downloading the file StaceyB1Notes.pdf from http://www.physics.ox.ac.uk/users/staceyd/ (a directory listing) and using gpdf for some time, I tried to switch back to Firefox and found only the window title bar and taskbar icon; the rest of the window had disappeared. Trying to close it from the taskbar brought up a stopped responding message, at which I selected Force Quit; this closed it, and unlike the previous problems, it could then be restarted successfully. Shortly after opening http://www.physics.ox.ac.uk/users/staceyd/ again (without downloading anything this time) and tabbing away from it within Firefox, Firefox hung and again had to be forced closed, but when I opened this page a third time in an attempt to reproduce the crash, it worked normally. Trace from both crashes: (gdb) run Starting program: /usr/lib/mozilla-firefox/firefox-bin -a firefox (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 1086683168 (LWP 4765)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 1097059248 (LWP 4766)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 1109744560 (LWP 4767)] [New Thread 1118133168 (LWP 4768)] [New Thread 1126521776 (LWP 4769)] (no debugging symbols found) (no debugging symbols found) [New Thread 1135676336 (LWP 4770)] (no debugging symbols found) [New Thread 1146092464 (LWP 4771)] [Thread 1146092464 (LWP 4771) exited] (no debugging symbols found) (no debugging symbols found) [Thread 1126521776 (LWP 4769) exited] [Thread 1109744560 (LWP 4767) exited] [Thread 1135676336 (LWP 4770) exited] [New Thread 1135676336 (LWP 4772)] [New Thread 1109744560 (LWP 4773)] [New Thread 1126521776 (LWP 4774)] [Thread 1135676336 (LWP 4772) exited] [Thread 1126521776 (LWP 4774) exited] [Thread 1109744560 (LWP 4773) exited] [New Thread 1109744560 (LWP 4776)] [New Thread 1126521776 (LWP 4777)] [New Thread 1135676336 (LWP 4778)] [Thread 1109744560 (LWP 4776) exited] [Thread 1126521776 (LWP 4777) exited] [New Thread 1126521776 (LWP 4811)] [New Thread 1109744560 (LWP 4817)] [Thread 1126521776 (LWP 4811) exited] [New Thread 1126521776 (LWP 4832)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGPIPE, Broken pipe. [Switching to Thread 1097059248 (LWP 4766)] 0x401a3ade in send () from /lib/tls/libpthread.so.0 (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/lib/mozilla-firefox/firefox-bin -a firefox (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging
