64bit: segfault on program exit
I am building and testing openmpi-1.7.0rc9 on CYGWIN_NT-6.1 1.7.18(0.263/5/3) 2013-03-28 22:07 x86_64 Cygwin every looks fine except when all the processes on several cores end and should return to lunching program, something go wrong (of course on 32bit everyhing is OK) Attached stackdump. $ mpirun -np 4 ./hello_c.exe Hello, world, I am 1 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 3 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 2 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 0 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) [MARCOATZERI:05260] *** Process received signal *** [MARCOATZERI:05260] Signal: Segmentation fault (11) [MARCOATZERI:05260] Signal code: (23) [MARCOATZERI:05260] Failing at address: 0x488f23380 [MARCOATZERI:05260] *** End of error message *** Segmentation fault debugging with gdb is not very useful as (gdb) run -np 4 ./hello_c.exe Starting program: /usr/bin/orterun.exe -np 4 ./hello_c.exe [New Thread 1964.0x23a8] [New Thread 1964.0x1554] [New Thread 1964.0x27dc] [New Thread 1964.0x1388] [New Thread 1964.0x5a4] [New Thread 1964.0x15bc] [New Thread 1964.0x23e4] [New Thread 1964.0x2244] [New Thread 1964.0x163c] [New Thread 1964.0x16f8] [New Thread 1964.0x2718] [New Thread 1964.0x2018] [New Thread 1964.0x19c4] Hello, world, I am 0 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 2 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 3 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 1 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) and gdb freezes. Marco Exception: STATUS_ACCESS_VIOLATION at rip=00488F23380 rax= rbx=0004 rcx=00018022C984 rdx= rsi=000600012270 rdi=000488F6C060 r8 =0001801C9DA0 r9 =000488F7E000 r10=000588F6C05F r11=000488F23367 r12= r13=0001 r14= r15=0006 rbp=0022A630 rsp=0022A610 program=E:\cygwin64\bin\orterun.exe, pid 5260, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 022A630 00488F23380 (004CCD4, 0060008C820, 00600082970, 022CCF0) 00600012500 00488F1C48C (000, 022AB10, 00180134344, 000) 022A900 0010040234B (022AB10, 000, 000, 022AB80) 022AAC0 001004010F3 (022AB10, 000, 030, 3000100FF00) 022AB80 001800478A7 (000, 000, 000, 000) 000 0018004576B (000, 000, 000, 000) 000 0018004592F (000, 000, 000, 000) 000 00100407CB1 (000, 000, 000, 000) 000 00100401010 (000, 000, 000, 000) 000 0007710652D (000, 000, 000, 00077189300) 000 0007733C521 (000, 000, 000, 00077189300) End of stack trace
64bit doxygen-1.8.3.1-1: compilation error [ATTN: Yaakov]
Yaakov, Thank you for building a 64-bit version of doxygen. As doxygen maintainer, I wanted to rebuild this myself (mainly so that it was built for linux-g++ rather than win32-g++). However, when I try to re-build your doxygen-1.8.3.1-1 package with cygport, I get the following error: sh: epstopdf: command not found error: Problems running epstopdf. Check your TeX installation! There is no TeX in the 64-bit distribution yet, so please could you describe how you managed to build this package. Many thanks in advance for your help, Dave.
Re: [64bit RFU] xmlstarlet-1.4.2-1
On 4/1/2013 2:43 PM, David Stacey wrote:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-host-directories --force-directories --cut-dirs=5 \
${BASEURL}/ZMxLdGuAOB/64bit/release/xmlstarlet/setup.hint \
${BASEURL}/-0L7Ciq1OA/64bit/release/xmlstarlet/xmlstarlet-1.4.2-1-src.tar.bz2
\
${BASEURL}/YUKx1I2ao8/64bit/release/xmlstarlet/xmlstarlet-1.4.2-1.tar.bz2 \
${BASEURL}/RmYWLRBzf0/64bit/release/xmlstarlet/xmlstarlet-debuginfo/setup.hint
\
${BASEURL}/OXEiqObJog/64bit/release/xmlstarlet/xmlstarlet-debuginfo/xmlstarlet-debuginfo-1.4.2-1.tar.bz2
This is my first 64-bit package, so I'd appreciate it if someone could
take a quick look at it. However it appears to work fine, and all the
built-in tests give the expected results.
Dave.
uploaded
[64bit RFU] xmlstarlet-1.4.2-1
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-host-directories --force-directories --cut-dirs=5 \
${BASEURL}/ZMxLdGuAOB/64bit/release/xmlstarlet/setup.hint \
${BASEURL}/-0L7Ciq1OA/64bit/release/xmlstarlet/xmlstarlet-1.4.2-1-src.tar.bz2
\
${BASEURL}/YUKx1I2ao8/64bit/release/xmlstarlet/xmlstarlet-1.4.2-1.tar.bz2 \
${BASEURL}/RmYWLRBzf0/64bit/release/xmlstarlet/xmlstarlet-debuginfo/setup.hint
\
${BASEURL}/OXEiqObJog/64bit/release/xmlstarlet/xmlstarlet-debuginfo/xmlstarlet-debuginfo-1.4.2-1.tar.bz2
This is my first 64-bit package, so I'd appreciate it if someone could
take a quick look at it. However it appears to work fine, and all the
built-in tests give the expected results.
Dave.
Re: 64bit: man misconfigured
On 1 April 2013 13:11, Thomas Wolff wrote: > Am 01.04.2013 14:03, schrieb Andy Koppe: > >> On 30 March 2013 11:17, Thomas Wolff wrote: >>> >>> Due to changed /etc/man.conf, man64 uses escape sequences for bold >>> display >>> while man32 uses backspace combinations. >> >> Backspace combinations? > > The traditional Unix way to indicate bold, by explicit "overprinting", like > B^HBO^HOL^HLD^HD. > Compare man ls > ls.man.out with 32/64 bit versions. Oh, I see. Apparently that's due to another change in the 32-bit source patch, where the -c option is added to the 'nroff' command line. (Note besides: confused as to how that overprinting trick could possibly work in a terminal, I learned that it is implemented by 'less', by translating it to SGR sequences. If you send ls.man.out directly to the terminal, you don't see any bold or underline because a backspace followed by a character will simply replace the previous character rather than do anything special.) Andy
Re: 64bit: man misconfigured
Am 01.04.2013 14:03, schrieb Andy Koppe: On 30 March 2013 11:17, Thomas Wolff wrote: Due to changed /etc/man.conf, man64 uses escape sequences for bold display while man32 uses backspace combinations. Backspace combinations? The traditional Unix way to indicate bold, by explicit "overprinting", like B^HBO^HOL^HLD^HD. Compare man ls > ls.man.out with 32/64 bit versions. However, the escape sequences are not by default interpreted by less (less -r would work), so that PAGER=less man ... produces garbage display. The 32-bit /etc/man.conf has this: PAGER /usr/bin/less -isrR Whereas the 64-bit one has this: PAGER /bin/less -is As Thomas alludes to, the -r option tells 'less' to pass escape characters through to the terminal rather than turn them into a highlighted "ESC". The 32-bit man sources have a source patch that contains the following, so I guess that hasn't been applied in the 64-bit version. -DEFAULTLESSOPT="-is" +DEFAULTLESSOPT="-isrR" Andy
Re: 64bit: man misconfigured
On 30 March 2013 11:17, Thomas Wolff wrote: > Due to changed /etc/man.conf, man64 uses escape sequences for bold display > while man32 uses backspace combinations. Backspace combinations? > However, the escape sequences are not by default interpreted by less (less > -r would work), > so that PAGER=less man ... produces garbage display. The 32-bit /etc/man.conf has this: PAGER /usr/bin/less -isrR Whereas the 64-bit one has this: PAGER /bin/less -is As Thomas alludes to, the -r option tells 'less' to pass escape characters through to the terminal rather than turn them into a highlighted "ESC". The 32-bit man sources have a source patch that contains the following, so I guess that hasn't been applied in the 64-bit version. -DEFAULTLESSOPT="-is" +DEFAULTLESSOPT="-isrR" Andy
