Mailing List Archive: MythTV: Dev

Seg Fault on HEAD build under win32

Index | Next | Previous | View Threaded

arnonm at gmail

May 12, 2008, 11:46 PM

Post #1 of 20 (1948 views)
Permalink

Seg Fault on HEAD build under win32

I have completed compiling the QT4 version under win32, and all the exe fail
to run, they seg fault immediately with exit code 5:

gdb trace:
Program received signal SIGSEGV, Segmentation fault.

Program received signal SIGSEGV, Segmentation fault.

Program received signal SIGSEGV, Segmentation fault.

Program exited with code 030000000005.

Is this the state of HEAD, or I am doing something wrong?

Arnon

nigel at ind

May 13, 2008, 12:53 AM

Post #2 of 20 (1916 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

> Is this the state of HEAD, or I am doing something wrong?
>

SVN head on Linux or Mac OS seem OK.

GDB trace?

--
Nigel Pearson, nigel[at]ind.tansu.com.au|"Look at this!
Telstra Net. Eng., Sydney, Australia | Do you think I put this in
Office: 9202 3900 Fax: 9261 3912 | to get better reception?"
Mobile: 0408 664435 Home: 9792 6998 | Batty - Fern Gully

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

arnonm at gmail

May 13, 2008, 2:41 AM

Post #3 of 20 (1898 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

That is the gdb trace :(
Compilation completes end to end: mythtv, themes, plugins, but it seg faults
when running.
Depends show that all the dependencies are in place.

Arnon

Date: Tue, May 13, 2008 at 10:38 AM
Subject: Re: Seg Fault on HEAD build under win32
To: arnonm[at]gmail.com

SVN head on Linux or Mac OS seem OK.

GDB trace?

--
Nigel Pearson, nigel[at]ind.tansu.com.au|"Look at this!
Telstra Net. Eng., Sydney, Australia | Do you think I put this in
Office: 9202 3900 Fax: 9261 3912 | to get better reception?"
Mobile: 0408 664435 Home: 9792 6998 | Batty - Fern Gully

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

arnonm at gmail

May 13, 2008, 3:58 AM

Post #4 of 20 (1900 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

> That is the gdb trace :(
> Compilation completes end to end: mythtv, themes, plugins, but it seg
> faults when running.
> Depends show that all the dependencies are in place.
>
> Arnon
>
> Date: Tue, May 13, 2008 at 10:38 AM
> Subject: Re: Seg Fault on HEAD build under win32
> To: arnonm[at]gmail.com
>
>
>
> SVN head on Linux or Mac OS seem OK.
>
>
>
> GDB trace?
>
> --
> Nigel Pearson, nigel[at]ind.tansu.com.au|"Look at this!
> Telstra Net. Eng., Sydney, Australia | Do you think I put this in
> Office: 9202 3900 Fax: 9261 3912 | to get better reception?"
> Mobile: 0408 664435 Home: 9792 6998 | Batty - Fern Gully
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>

davidbuzz at gmail

May 14, 2008, 5:57 PM

Post #5 of 20 (1874 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Arnonm,

You are not alone, I got these exact same symptoms yesterday when I got my
Win32 build built. I assumed I'd screwed up, and was going to try again
from scratch tonite, but now I feel better about my situation. :-)

All Applications crash IMMEDIATELY, with nothing but a SIGSEV. no GUI, no
output, nothing. same symptoms on all .exe's: backend, frontend,
welcome, etc.

Buzz.

arnonm at gmail

May 15, 2008, 2:41 AM

Post #6 of 20 (1865 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Buzz,

Just did a complete rebuild, started with PERL only on the machine (no
ming,msys, qt or mythtv) and same result. SEGFault without any output. Given
that QT examples work, I am pretty sure it is out library linking that is
not working - perhaps need to examine the workarounds done for library
names.

Attached is my latest win32-packager. It builds QT4 distribution end to end.
A few changes I made:
- minor bug fix for qmake QT4 to fix extra installs (aka inc.files=)
- minor fixes to pro files to install properly - ticket 5332 - currently
applied as a patch until it is in head
- installs mythtv first to /usr/local/ and then to build. This resolves the
depedencies for mythplugins and also gives a stable install

No code changes to myth- all are related to qmake installation routines

Arnon

On 5/15/08, Arnon Meshoulam (arnonm) <arnonm[at]gmail.com> wrote:
>
> Arnonm,
>
> You are not alone, I got these exact same symptoms yesterday when I got my
> Win32 build built. I assumed I'd screwed up, and was going to try again
> from scratch tonite, but now I feel better about my situation. :-)
>
> All Applications crash IMMEDIATELY, with nothing but a SIGSEV. no GUI, no
> output, nothing. same symptoms on all .exe's: backend, frontend,
> welcome, etc.
>
> Buzz.

Attachments:

win32-packager.diff (25.4 KB)

davidbuzz at gmail

May 15, 2008, 5:15 AM

Post #7 of 20 (1864 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

I've just had a quick glance through your patch, and it looks like you
have a few really good things in there, and a couple of things I'm
uncertain about....

0) what are you patches against? it seems like you have use an
older version of the script, and then diffed against HEAD? these are
a lot of changes in the .diff file that I don't think are yours, are
they?

1) As you've started installing to /usr/local instead of /usr ... it
appears to be so that you can just copy the entire contents of 'local'
into 'build' later and delete it! ? That's far from perfect,
especially if msys/ming users have other stuff that they have chosen
to install into /usr/local/
Perhaps checking if it already exists at the start, and failing would
be a reasonable compromise.... "build aborted /usr/local must be empty
initially" or some other BS.
A better solution (in my view anyway) is to pick-n-choose the precise
files needed in the 'build' folder, and copy them into the 'build'
folder on-demand. that way, the files aren't re-installed to
/usr/local, relocated, and then deleted every time the script is run.
the result being that repeat runs are quicker then?.

2) the patches to QT4 (qt4_install_helpers.patch) are definitely
something that we want (assuming no-one has any better ideas that
avoid patching QT) , so we should get these checked-in to the build
script ASAP.

3) ticket 5331/5332 should be reviewed by a dev with commit
access (Nigel, or anyone else feeling helpful!) .

4) these tweaks to settings.pro (and plugins settings.pro too) seem a
good idea to me too, so I think they should just get committed to the
.pro files directly= !
win32:QMAKE_INSTALL_DIR = sh ./cpsvndir
win32:DEPENDS += ./
win32:QMAKE_MKDIR = mkdir -p

No further comments except to say good work! It's nice to have
other people involved, now we just need more ! :-)

Buzz.

On Thu, May 15, 2008 at 7:41 PM, Arnon Meshoulam (arnonm)
<arnonm[at]gmail.com> wrote:
> Buzz,
>
> Just did a complete rebuild, started with PERL only on the machine (no
> ming,msys, qt or mythtv) and same result. SEGFault without any output. Given
> that QT examples work, I am pretty sure it is out library linking that is
> not working - perhaps need to examine the workarounds done for library
> names.
>
> Attached is my latest win32-packager. It builds QT4 distribution end to end.
> A few changes I made:
> - minor bug fix for qmake QT4 to fix extra installs (aka inc.files=)
> - minor fixes to pro files to install properly - ticket 5332 - currently
> applied as a patch until it is in head
> - installs mythtv first to /usr/local/ and then to build. This resolves the
> depedencies for mythplugins and also gives a stable install
>
> No code changes to myth- all are related to qmake installation routines
>
> Arnon
>
> On 5/15/08, Arnon Meshoulam (arnonm) <arnonm[at]gmail.com> wrote:
>>
>> Arnonm,
>>
>> You are not alone, I got these exact same symptoms yesterday when I got my
>> Win32 build built. I assumed I'd screwed up, and was going to try again
>> from scratch tonite, but now I feel better about my situation. :-)
>>
>> All Applications crash IMMEDIATELY, with nothing but a SIGSEV. no GUI, no
>> output, nothing. same symptoms on all .exe's: backend, frontend,
>> welcome, etc.
>>
>> Buzz.
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

nigel at ind

May 15, 2008, 7:45 PM

Post #8 of 20 (1844 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

On 15/05/2008, at 7:41 PM, Arnon Meshoulam (arnonm) wrote:

> - minor bug fix for qmake QT4

Thanks for that. It isn't perfect yet, but it is getting closer:

$ cd /c/mythtv/mythtv/themes

$ echo PREFIX=/usr >>../config.mak
$ qmake *.pro
$ egrep FreeSans Makefile.Debug
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSans.ttf $
(INSTALL_ROOT)/usr/share/mythtv/
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSansBold.ttf $
(INSTALL_ROOT)/usr/share/mythtv/
-$(DEL_FILE) -r $(INSTALL_ROOT)/usr/share/mythtv/FreeSans.ttf
-$(DEL_FILE) -r $(INSTALL_ROOT)/usr/share/mythtv/
FreeSansBold.ttf

$ echo PREFIX=\\mythtv\\build\\plugins >>../config.mak
$ qmake *.pro
$ egrep FreeSans Makefile.Debug
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSans.ttf $
(INSTALL_ROOT)/mythtv/build/plugins/share/mythtv/
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSansBold.ttf $
(INSTALL_ROOT)/mythtv/build/plugins/share/mythtv/
-$(DEL_FILE) -r $(INSTALL_ROOT)/mythtv/build/plugins/share/
mythtv/FreeSans.ttf
-$(DEL_FILE) -r $(INSTALL_ROOT)/mythtv/build/plugins/share/
mythtv/FreeSansBold.ttf

$ echo 'PREFIX=C:\mythtv\build\plugins' >>../config.mak
$ qmake *.pro
$ egrep FreeSans Makefile.Debug
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSans.ttf c:$
(INSTALL_ROOT)/mythtv/build/plugins/share/mythtv/
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSansBold.ttf c:$
(INSTALL_ROOT)/mythtv/build/plugins/share/mythtv/
-$(DEL_FILE) -r c:$(INSTALL_ROOT)/mythtv/build/plugins/share/
mythtv/FreeSans.ttf
-$(DEL_FILE) -r c:$(INSTALL_ROOT)/mythtv/build/plugins/
share/mythtv/FreeSansBold.ttf

$ echo PREFIX=plugins >>../config.mak
$ qmake *.pro
$ egrep FreeSans Makefile.Debug
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSans.ttf c:$
(INSTALL_ROOT)/mythtv/mythtv/themes/plugins/share/mythtv/
-$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSansBold.ttf c:$
(INSTALL_ROOT)/mythtv/mythtv/themes/plugins/share/mythtv/
-$(DEL_FILE) -r c:$(INSTALL_ROOT)/mythtv/mythtv/themes/
plugins/share/mythtv/FreeSans.ttf
-$(DEL_FILE) -r c:$(INSTALL_ROOT)/mythtv/mythtv/themes/
plugins/share/mythtv/FreeSansBold.ttf

If the target doesn't look like an absolute path
(either DOS or MinGW format), then it has problems.

--
Nigel Pearson, nigel[at]ind.tansu.com.au|"In this city I confess;
Telstra Net. Eng., Sydney, Australia | god is mammon, more is less.
Office: 9202 3900 Fax: 9261 3912 | Off like lemmings at the gun!
Mobile: 0408 664435 Home: 9792 6998 | I know better, still I run"

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

davidbuzz at gmail

May 16, 2008, 12:31 AM

Post #9 of 20 (1831 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Arnonm,
There was a mention in one of the references of a shell script that
could be run across all the DLL's to determine of they contain .rdata
areas (ie read-only data areas populated by use of the 'const'
keyword). perhaps doing that will help identify which dll's are
likely candidates for re-compiling using this script? Cause there are
a LOT of dll's in there that could be the cause, including all the QT4
ones.! (my suspicion!)

Buzz.

On Fri, May 16, 2008 at 4:31 PM, Arnon Meshoulam
<arnon.meshoulam[at]googlemail.com> wrote:
> Same conclusion. I played last night with just linking mythfrontend with
> this script, with no effect. I'll try today to do the whole chain of DLLs
> and see.
>
> arnon
>
>
> On 5/16/08, buzz <davidbuzz[at]gmail.com> wrote:
>>
>> >Totally beyond me, but does it help?
>> >http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/4210.html
>>
>>
>> Yes, that helps. (especially the first link that they refer to:
>> http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html )
>>
>> Basically it means that (at least under mingw/msys) that 'extern
>> const' is NOT allowed to refer to a DATA section (eg: extern const
>> struct ) if any/all of the data comes from a DLL.
>>
>> posible solutions:
>> 1) search through all mythtv code for 'extern const' and if its
>> referring to data (like a struct) then it MIGHT be suspicious,
>> especially if the code and data refered to is in different DLL's.
>> Remove the offending 'const' keyword where relevant to fix each
>> instance.
>>
>> 2) Link all DLL's without .rdata sections, by using a specific linker
>> script, which avoids rdata
>> sections. (script is appended).
>> Copy the linker script for example to /usr/lib/ldscripts and run the
>> following
>> line to link a dll.
>> gcc -Wl,--script,/usr/lib/ldscripts/i386pe.x-no-rdata
>>
>> Please note, I have not tried either of these, yet. I'm just
>> summarizing the research.
>>
>> taken from:
>> http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html
>> http://www.cygwin.com/ml/cygwin/2007-07/msg00470.html
>> http://www.cygwin.com/ml/cygwin/2004-10/msg01052.html
>>
>> Buzz.
>>
>>
>>
>> /* specific linker script avoiding .rdata sections, for normal executables
>> for a reference see
>> http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html
>> http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00309.html
>> */
>> OUTPUT_FORMAT(pei-i386)
>> SEARCH_DIR("/usr/i686-pc-cygwin/lib"); SEARCH_DIR("/usr/lib");
>> SEARCH_DIR("/usr/lib/w32api");
>> ENTRY(_mainCRTStartup)
>> SECTIONS
>> {
>> .text __image_base__ + __section_alignment__ :
>> {
>> *(.init)
>> *(.text)
>> *(SORT(.text$*))
>> *(.glue_7t)
>> *(.glue_7)
>> ___CTOR_LIST__ = .; __CTOR_LIST__ = . ;
>> LONG (-1);*(.ctors); *(.ctor);
>> *(SORT(.ctors.*)); LONG (0);
>> ___DTOR_LIST__ = .; __DTOR_LIST__ = . ;
>> LONG (-1); *(.dtors); *(.dtor);
>> *(SORT(.dtors.*)); LONG (0);
>> *(.fini)
>> /* ??? Why is .gcc_exc here? */
>> *(.gcc_exc)
>> PROVIDE (etext = .);
>> *(.gcc_except_table)
>> }
>> /* The Cygwin32 library uses a section to avoid copying certain data
>> on fork. This used to be named ".data". The linker used
>> to include this between __data_start__ and __data_end__, but that
>> breaks building the cygwin32 dll. Instead, we name the section
>> ".data_cygwin_nocopy" and explictly include it after __data_end__. */
>> .data BLOCK(__section_alignment__) :
>> {
>> __data_start__ = . ;
>> *(.data)
>> *(.data2)
>> *(SORT(.data$*))
>> *(.rdata)
>> *(SORT(.rdata$*))
>> *(.eh_frame)
>> ___RUNTIME_PSEUDO_RELOC_LIST__ = .;
>> __RUNTIME_PSEUDO_RELOC_LIST__ = .;
>> *(.rdata_runtime_pseudo_reloc)
>> ___RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
>> __RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
>> __data_end__ = . ;
>> *(.data_cygwin_nocopy)
>> }
>> .rdata BLOCK(__section_alignment__) :
>> {
>> }
>> .pdata BLOCK(__section_alignment__) :
>> {
>> *(.pdata)
>> }
>> .bss BLOCK(__section_alignment__) :
>> {
>> __bss_start__ = . ;
>> *(.bss)
>> *(COMMON)
>> __bss_end__ = . ;
>> }
>> .edata BLOCK(__section_alignment__) :
>> {
>> *(.edata)
>> }
>> /DISCARD/ :
>> {
>> *(.debug$S)
>> *(.debug$T)
>> *(.debug$F)
>> *(.drectve)
>> }
>> .idata BLOCK(__section_alignment__) :
>> {
>> /* This cannot currently be handled with grouped sections.
>> See pe.em:sort_sections. */
>> SORT(*)(.idata$2)
>> SORT(*)(.idata$3)
>> /* These zeroes mark the end of the import list. */
>> LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
>> SORT(*)(.idata$4)
>> SORT(*)(.idata$5)
>> SORT(*)(.idata$6)
>> SORT(*)(.idata$7)
>> }
>> .CRT BLOCK(__section_alignment__) :
>> {
>> ___crt_xc_start__ = . ;
>> *(SORT(.CRT$XC*)) /* C initialization */
>> ___crt_xc_end__ = . ;
>> ___crt_xi_start__ = . ;
>> *(SORT(.CRT$XI*)) /* C++ initialization */
>> ___crt_xi_end__ = . ;
>> ___crt_xl_start__ = . ;
>> *(SORT(.CRT$XL*)) /* TLS callbacks */
>> /* ___crt_xl_end__ is defined in the TLS Directory support code */
>> ___crt_xp_start__ = . ;
>> *(SORT(.CRT$XP*)) /* Pre-termination */
>> ___crt_xp_end__ = . ;
>> ___crt_xt_start__ = . ;
>> *(SORT(.CRT$XT*)) /* Termination */
>> ___crt_xt_end__ = . ;
>> }
>> .tls BLOCK(__section_alignment__) :
>> {
>> ___tls_start__ = . ;
>> *(.tls)
>> *(.tls$)
>> *(SORT(.tls$*))
>> ___tls_end__ = . ;
>> }
>> .endjunk BLOCK(__section_alignment__) :
>> {
>> /* end is deprecated, don't use it */
>> PROVIDE (end = .);
>> PROVIDE ( _end = .);
>> __end__ = .;
>> }
>> .rsrc BLOCK(__section_alignment__) :
>> {
>> *(.rsrc)
>> *(SORT(.rsrc$*))
>> }
>> .reloc BLOCK(__section_alignment__) :
>> {
>> *(.reloc)
>> }
>> .stab BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.stab)
>> }
>> .stabstr BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.stabstr)
>> }
>> /* DWARF debug sections.
>> Symbols in the DWARF debugging sections are relative to the beginning
>> of the section. Unlike other targets that fake this by putting the
>> section VMA at 0, the PE format will not allow it. */
>> /* DWARF 1.1 and DWARF 2. */
>> .debug_aranges BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_aranges)
>> }
>> .debug_pubnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_pubnames)
>> }
>> /* DWARF 2. */
>> .debug_info BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_info) *(.gnu.linkonce.wi.*)
>> }
>> .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_abbrev)
>> }
>> .debug_line BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_line)
>> }
>> .debug_frame BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_frame)
>> }
>> .debug_str BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_str)
>> }
>> .debug_loc BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_loc)
>> }
>> .debug_macinfo BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_macinfo)
>> }
>> /* SGI/MIPS DWARF 2 extensions. */
>> .debug_weaknames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_weaknames)
>> }
>> .debug_funcnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_funcnames)
>> }
>> .debug_typenames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_typenames)
>> }
>> .debug_varnames BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_varnames)
>> }
>> /* DWARF 3. */
>> .debug_ranges BLOCK(__section_alignment__) (NOLOAD) :
>> {
>> *(.debug_ranges)
>> }
>> }
>
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

nigel at ind

May 16, 2008, 1:12 AM

Post #10 of 20 (1829 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

> perhaps doing that will help identify which dll's are
> likely candidates for re-compiling using this script? Cause there are
> a LOT of dll's in there that could be the cause, including all the QT4
> ones.! (my suspicion!)

I suspect recent changes to libmyth
because about 3 weeks ago,
I thought I did have a working SVN build.

--
Nigel Pearson, nigel[at]ind.tansu.com.au| 4 8
Telstra Net. Eng., Sydney, Australia | 15 16
Office: 9202 3900 Fax: 9261 3912 | 23 42
Mobile: 0408 664435 Home: 9792 6998 | Lost

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

arnonm at gmail

May 16, 2008, 5:29 AM

Post #11 of 20 (1800 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Nigel,

To test it out, I started fresh with a copy of 17167, 17200 and 17222 - all
with the same results
I also removed the DEPENDS+=./ in case that was affecting it.

Should we be going back earlier?

Arnon

On 5/16/08, Nigel Pearson <nigel[at]ind.tansu.com.au> wrote:
>
> perhaps doing that will help identify which dll's are
>> likely candidates for re-compiling using this script? Cause there are
>> a LOT of dll's in there that could be the cause, including all the QT4
>> ones.! (my suspicion!)
>>
>
> I suspect recent changes to libmyth
> because about 3 weeks ago,
> I thought I did have a working SVN build.
>
> --
> Nigel Pearson, nigel[at]ind.tansu.com.au| 4 8
> Telstra Net. Eng., Sydney, Australia | 15 16
> Office: 9202 3900 Fax: 9261 3912 | 23 42
> Mobile: 0408 664435 Home: 9792 6998 | Lost
>
>
>
>

nigel at ind

May 16, 2008, 11:30 PM

Post #12 of 20 (1764 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

On 5/16/08, Nigel Pearson <nigel[at]ind.tansu.com.au> wrote:
> $ echo PREFIX=plugins >>../config.mak
> $ qmake *.pro
> $ egrep FreeSans Makefile.Debug
> -$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSans.ttf c:$
> (INSTALL_ROOT)/mythtv/mythtv/themes/plugins/share/mythtv/
> -$(INSTALL_FILE) c:/mythtv/mythtv/themes/FreeSansBold.ttf c:$
> (INSTALL_ROOT)/mythtv/mythtv/themes/plugins/share/mythtv/
> -$(DEL_FILE) -r c:$(INSTALL_ROOT)/mythtv/mythtv/themes/
> plugins/share/mythtv/FreeSans.ttf
> -$(DEL_FILE) -r c:$(INSTALL_ROOT)/mythtv/mythtv/themes/
> plugins/share/mythtv/FreeSansBold.ttf
>
>
> If the target doesn't look like an absolute path
> (either DOS or MinGW format), then it has problems.

On 16/05/2008, at 4:29 PM, Arnon Meshoulam wrote:
> Good catch - it doesn't solve all the scenarios.

I was wrong, this is the behavior on Unix too.
For relative target paths, Qmake's fileFixify()
always prepends the current directory.

--
Nigel Pearson, nigel[at]ind.tansu.com.au|
Telstra Net. Eng., Sydney, Australia |
Office: 9202 3900 Fax: 9261 3912 |
Mobile: 0408 664435 Home: 9792 6998 |

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

arnonm at gmail

May 17, 2008, 11:47 PM

Post #13 of 20 (1720 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

I gave 16790 a try, with same results. Had to make two or three code changes
to get it to compile (later patches) and lots of dll renaming, but end
result is the same - exe segfault with "Can't Initialize properly".

Arnon

On 5/17/08, Nigel Pearson <nigel[at]ind.tansu.com.au> wrote:
>
> Back to 17140 without success..
>> Did we ever have a working QT4 version?
>>
>
>
> I seem to recall 16790, but that VM image is long gone,
> so that may not even be in the current branch (trunk).
>
> --
> Nigel Pearson, nigel[at]ind.tansu.com.au|The weak point of
> Telstra Net. Eng., Sydney, Australia | the modern car is
> Office: 9202 3900 Fax: 9261 3912 | the squidgy organic
> Mobile: 0408 664435 Home: 9792 6998 | bit behind the wheel.
>
>

arnonm at gmail

May 19, 2008, 3:36 AM

Post #14 of 20 (1673 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

I have been using OllyDbg to look at the code. Culpruit seems to be libmyth.
I am still working through the loading steps but there is a constant
segfault with MythDialog16staticMetaObject.
We seem to be doing lots of reference to the object, such as:

const QMetaObject RecOptDialog::staticMetaObject = {
{ &MythDialog::staticMetaObject, qt_meta_stringdata_RecOptDialog,
qt_meta_data_RecOptDialog, 0 }
};
but it is getting beyond my depth.

Arnon

On 5/18/08, Arnon Meshoulam (arnonm) <arnonm[at]gmail.com> wrote:
>
> I gave 16790 a try, with same results. Had to make two or three code
> changes to get it to compile (later patches) and lots of dll renaming, but
> end result is the same - exe segfault with "Can't Initialize properly".
>
> Arnon
>
> On 5/17/08, Nigel Pearson <nigel[at]ind.tansu.com.au> wrote:
>>
>> Back to 17140 without success..
>>> Did we ever have a working QT4 version?
>>>
>>
>>
>> I seem to recall 16790, but that VM image is long gone,
>> so that may not even be in the current branch (trunk).
>>
>> --
>> Nigel Pearson, nigel[at]ind.tansu.com.au|The weak point of
>> Telstra Net. Eng., Sydney, Australia | the modern car is
>> Office: 9202 3900 Fax: 9261 3912 | the squidgy organic
>> Mobile: 0408 664435 Home: 9792 6998 | bit behind the wheel.
>>
>>
>

davidbuzz at gmail

May 19, 2008, 5:25 PM

Post #15 of 20 (1650 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Nice work so far, clearly you have way more time than the rest of us!
.... :-)

I'd look at this 'const' declaration suspiciously, and in the context
of the error we are having here, I'd think that if any of the three
variables inside the const could actually be a pointer to a variable
in a/another .dll, then that's probably where the issue lies, then the
'const' keyword needs to be removed from here, supposedly. (untested
theory only).

if we are really "doing lots of reference to the object", then we can
expect lots of segfaults :-)

I wonder why QT3 builds didn't suffer from this problem?

Buzz.

On Mon, May 19, 2008 at 8:36 PM, Arnon Meshoulam (arnonm)
<arnonm[at]gmail.com> wrote:
> I have been using OllyDbg to look at the code. Culpruit seems to be libmyth.
> I am still working through the loading steps but there is a constant
> segfault with MythDialog16staticMetaObject.
> We seem to be doing lots of reference to the object, such as:
>
> const QMetaObject RecOptDialog::staticMetaObject = {
> { &MythDialog::staticMetaObject, qt_meta_stringdata_RecOptDialog,
> qt_meta_data_RecOptDialog, 0 }
> };
> but it is getting beyond my depth.
>
> Arnon
>
>
> On 5/18/08, Arnon Meshoulam (arnonm) <arnonm[at]gmail.com> wrote:
>>
>> I gave 16790 a try, with same results. Had to make two or three code
>> changes to get it to compile (later patches) and lots of dll renaming, but
>> end result is the same - exe segfault with "Can't Initialize properly".
>> Arnon
>>
>> On 5/17/08, Nigel Pearson <nigel[at]ind.tansu.com.au> wrote:
>>>>
>>>> Back to 17140 without success..
>>>> Did we ever have a working QT4 version?
>>>
>>>
>>> I seem to recall 16790, but that VM image is long gone,
>>> so that may not even be in the current branch (trunk).
>>>
>>> --
>>> Nigel Pearson, nigel[at]ind.tansu.com.au|The weak point of
>>> Telstra Net. Eng., Sydney, Australia | the modern car is
>>> Office: 9202 3900 Fax: 9261 3912 | the squidgy organic
>>> Mobile: 0408 664435 Home: 9792 6998 | bit behind the wheel.
>>>
>>
>
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

nigel at ind

May 20, 2008, 4:58 PM

Post #16 of 20 (1610 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

> variables inside the const could actually be a pointer to a variable
> in a/another .dll

As an experiment (if you have the time, I haven't tried it on Windows
yet)

try applying:
http://svn.mythtv.org/trac/attachment/ticket/4264/combine-libs.patch

It hacks out the nasty dependencies between libmyth,
libmythui and libmythupnp by amalgamating their code.

Probably best to delete all libmythui-0.22.dll
and libmythupnp-0.22.dll first, though.
(and I had to delete mtd and ignyte
from plugins to force their relink)

--
Nigel Pearson, nigel[at]ind.tansu.com.au|"Beware - I am a carrier
Telstra Net. Eng., Sydney, Australia | of surrealism"
Office: 9202 3900 Fax: 9261 3912 | D A
Mobile: 0408 664435 Home: 9792 6998 | L I

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

arnonm at gmail

May 21, 2008, 12:44 AM

Post #17 of 20 (1602 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Nigel,

I tried the experiment
make clean
patch
make
make install

Results:
libmyth is build as libliblibmyth-0.22.dll
libmythtv looks for libmyth-0.22.dll and cant find it (a copy solved that)
During runtime mythfrontend looks for libliblibmyth-0.22.dll again
Once it is in place, same segfault - can't initialize properly :(

On Wed, May 21, 2008 at 12:58 AM, Nigel Pearson <nigel[at]ind.tansu.com.au>
wrote:

>
> variables inside the const could actually be a pointer to a variable
>> in a/another .dll
>>
>
> As an experiment (if you have the time, I haven't tried it on Windows yet)
>
>
> try applying:
> http://svn.mythtv.org/trac/attachment/ticket/4264/combine-libs.patch
>
>
> It hacks out the nasty dependencies between libmyth,
> libmythui and libmythupnp by amalgamating their code.
>
> Probably best to delete all libmythui-0.22.dll
> and libmythupnp-0.22.dll first, though.
> (and I had to delete mtd and ignyte
> from plugins to force their relink)
>
> --
> Nigel Pearson, nigel[at]ind.tansu.com.au|"Beware - I am a carrier
> Telstra Net. Eng., Sydney, Australia | of surrealism"
> Office: 9202 3900 Fax: 9261 3912 | D A
> Mobile: 0408 664435 Home: 9792 6998 | L I
>
>

mark.buechler at gmail

Jun 26, 2008, 1:50 PM

Post #18 of 20 (1048 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Hi

On Wed, May 21, 2008 at 3:44 AM, Arnon Meshoulam (arnonm) <arnonm[at]gmail.com>
wrote:

> Nigel,
>
> I tried the experiment
> make clean
> patch
> make
> make install
>
> Results:
> libmyth is build as libliblibmyth-0.22.dll
> libmythtv looks for libmyth-0.22.dll and cant find it (a copy solved that)
> During runtime mythfrontend looks for libliblibmyth-0.22.dll again
> Once it is in place, same segfault - can't initialize properly :(
>

Has there been anymore work done on this recently?

Thanks, Mark.

>
>
> On Wed, May 21, 2008 at 12:58 AM, Nigel Pearson <nigel[at]ind.tansu.com.au>
> wrote:
>
>>
>> variables inside the const could actually be a pointer to a variable
>>> in a/another .dll
>>>
>>
>> As an experiment (if you have the time, I haven't tried it on Windows yet)
>>
>>
>> try applying:
>> http://svn.mythtv.org/trac/attachment/ticket/4264/combine-libs.patch
>>
>>
>> It hacks out the nasty dependencies between libmyth,
>> libmythui and libmythupnp by amalgamating their code.
>>
>> Probably best to delete all libmythui-0.22.dll
>> and libmythupnp-0.22.dll first, though.
>> (and I had to delete mtd and ignyte
>> from plugins to force their relink)
>>
>> --
>> Nigel Pearson, nigel[at]ind.tansu.com.au|"Beware - I am a carrier
>> Telstra Net. Eng., Sydney, Australia | of surrealism"
>> Office: 9202 3900 Fax: 9261 3912 | D A
>> Mobile: 0408 664435 Home: 9792 6998 | L I
>>
>>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>

davidbuzz at gmail

Jun 27, 2008, 3:31 AM

Post #19 of 20 (1021 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Mark,
Yes, much work is being done. Nigel and Arnonm have been doing a lot
of work mopping up errors/warnings in the win32 build scripts/code,
and I believe that the QT3 based code in 21-fixes is near-enough to
functional, and will be release ready soon. the QT4 based code in
HEAD builds to completion, but it's currently suffering from a
critical failure that prevents any of the executables from running
except mtd.exe, and we are at a bit of a loss as to why.

FYI - this is the error that is reported IMMEDIATELY on startup, there
is no stacktrace or any information from GDB - if anyone can help with
this, it'd be appreciated!

Program received signal SIGSEGV, Segmentation fault.
Program exited with code 030000000005.

Buzz.

On Fri, Jun 27, 2008 at 6:50 AM, Mark Buechler <mark.buechler[at]gmail.com> wrote:
> Hi
>
> On Wed, May 21, 2008 at 3:44 AM, Arnon Meshoulam (arnonm) <arnonm[at]gmail.com>
> wrote:
>>
>> Nigel,
>>
>> I tried the experiment
>> make clean
>> patch
>> make
>> make install
>>
>> Results:
>> libmyth is build as libliblibmyth-0.22.dll
>> libmythtv looks for libmyth-0.22.dll and cant find it (a copy solved that)
>> During runtime mythfrontend looks for libliblibmyth-0.22.dll again
>> Once it is in place, same segfault - can't initialize properly :(
>
> Has there been anymore work done on this recently?
>
> Thanks, Mark.
>
>>
>> On Wed, May 21, 2008 at 12:58 AM, Nigel Pearson <nigel[at]ind.tansu.com.au>
>> wrote:
>>>
>>>> variables inside the const could actually be a pointer to a variable
>>>> in a/another .dll
>>>
>>> As an experiment (if you have the time, I haven't tried it on Windows
>>> yet)
>>>
>>>
>>> try applying:
>>> http://svn.mythtv.org/trac/attachment/ticket/4264/combine-libs.patch
>>>
>>>
>>> It hacks out the nasty dependencies between libmyth,
>>> libmythui and libmythupnp by amalgamating their code.
>>>
>>> Probably best to delete all libmythui-0.22.dll
>>> and libmythupnp-0.22.dll first, though.
>>> (and I had to delete mtd and ignyte
>>> from plugins to force their relink)
>>>
>>> --
>>> Nigel Pearson, nigel[at]ind.tansu.com.au|"Beware - I am a carrier
>>> Telstra Net. Eng., Sydney, Australia | of surrealism"
>>> Office: 9202 3900 Fax: 9261 3912 | D A
>>> Mobile: 0408 664435 Home: 9792 6998 | L I
>>>
>>
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev[at]mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mark.buechler at gmail

Jun 27, 2008, 3:51 AM

Post #20 of 20 (1021 views)
Permalink

Re: Seg Fault on HEAD build under win32 [In reply to]

Hi

On Fri, Jun 27, 2008 at 6:31 AM, buzz <davidbuzz[at]gmail.com> wrote:

> Mark,
> Yes, much work is being done. Nigel and Arnonm have been doing a lot
> of work mopping up errors/warnings in the win32 build scripts/code,
> and I believe that the QT3 based code in 21-fixes is near-enough to
> functional, and will be release ready soon. the QT4 based code in
> HEAD builds to completion, but it's currently suffering from a
> critical failure that prevents any of the executables from running
> except mtd.exe, and we are at a bit of a loss as to why.
>

Thanks, I'm interested mainly in trunk.

>
> FYI - this is the error that is reported IMMEDIATELY on startup, there
> is no stacktrace or any information from GDB - if anyone can help with
> this, it'd be appreciated!
>
> Program received signal SIGSEGV, Segmentation fault.
> Program exited with code 030000000005.
>

Yes, it seems they're all segfaulting prior to main() so it would seem the
build is bad.

- Mark.

>
> Buzz.
>
> On Fri, Jun 27, 2008 at 6:50 AM, Mark Buechler <mark.buechler[at]gmail.com>
> wrote:
> > Hi
> >
> > On Wed, May 21, 2008 at 3:44 AM, Arnon Meshoulam (arnonm) <
> arnonm[at]gmail.com>
> > wrote:
> >>
> >> Nigel,
> >>
> >> I tried the experiment
> >> make clean
> >> patch
> >> make
> >> make install
> >>
> >> Results:
> >> libmyth is build as libliblibmyth-0.22.dll
> >> libmythtv looks for libmyth-0.22.dll and cant find it (a copy solved
> that)
> >> During runtime mythfrontend looks for libliblibmyth-0.22.dll again
> >> Once it is in place, same segfault - can't initialize properly :(
> >
> > Has there been anymore work done on this recently?
> >
> > Thanks, Mark.
> >
> >>
> >> On Wed, May 21, 2008 at 12:58 AM, Nigel Pearson <nigel[at]ind.tansu.com.au
> >
> >> wrote:
> >>>
> >>>> variables inside the const could actually be a pointer to a variable
> >>>> in a/another .dll
> >>>
> >>> As an experiment (if you have the time, I haven't tried it on Windows
> >>> yet)
> >>>
> >>>
> >>> try applying:
> >>> http://svn.mythtv.org/trac/attachment/ticket/4264/combine-libs.patch
> >>>
> >>>
> >>> It hacks out the nasty dependencies between libmyth,
> >>> libmythui and libmythupnp by amalgamating their code.
> >>>
> >>> Probably best to delete all libmythui-0.22.dll
> >>> and libmythupnp-0.22.dll first, though.
> >>> (and I had to delete mtd and ignyte
> >>> from plugins to force their relink)
> >>>
> >>> --
> >>> Nigel Pearson, nigel[at]ind.tansu.com.au|"Beware - I am a carrier
> >>> Telstra Net. Eng., Sydney, Australia | of surrealism"
> >>> Office: 9202 3900 Fax: 9261 3912 | D A
> >>> Mobile: 0408 664435 Home: 9792 6998 | L I
> >>>
> >>
> >>
> >> _______________________________________________
> >> mythtv-dev mailing list
> >> mythtv-dev[at]mythtv.org
> >> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> >>
> >
> >
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev[at]mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> >
> >
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com