Re: [Flightgear-devel] terragear-cs segfault
On Sat, Apr 23, 2011 at 5:00 PM, Christian Schmitt ch...@ilovelinux.de wrote: Csaba Halász wrote: Hm, ok, that doesn't seem to be SSE related, it's just your everyday NULL pointer. Have to check source code to see how that can happen. Did you look into this already? Yes. Would be a good start to fix this (if the problem is not IN the gpc lib). Don't know where the problem is. Unfortunately, the gpc code in question isn't trivial. In the invocation merge_left(cf, edge-outp[BELOW], out_poly); the second parameter seems to be NULL, but how that is calculated isn't obvious. -- Csaba/Jester -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: Hm, ok, that doesn't seem to be SSE related, it's just your everyday NULL pointer. Have to check source code to see how that can happen. Did you look into this already? Would be a good start to fix this (if the problem is not IN the gpc lib). Chris -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Geoff McLane wrote: I know and read some, like Martin, want to go perhaps another direction, and that too is fine... Well, what I am (we are) having in mind is to provide some sort of a scenery root node to FlightGear in the way like you're typically referencing OpenFlight scenarios. This _might_ lead to different scenery formats in the long term but there's no reason which impedes providing such a feature by replacing directory names and STG-files with a slightly different 'metadata' infrastructure around the same flavour of BTG-files we're using today. This would at least serve as a start, simply by moving the Scenery directory logic out of hard-coded source into the Scenery itself. But until we're starting to target the directory logic, there are more pressing issues to solve Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, 2011-04-18 at 16:14 +0200, Csaba Halász wrote: On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt ch...@ilovelinux.de wrote: Csaba Halász wrote: Info registers, and something like x/10i $eip (or $rip on 64 bit) Here you go (still on Atom), Phenom this evening. (gdb) info registers eax0x0 0 (gdb) x/10i $eip = 0xb7fb8fdd merge_left+9: mov0x14(%eax),%eax Hm, ok, that doesn't seem to be SSE related, it's just your everyday NULL pointer. Have to check source code to see how that can happen. Hi, Quite some time ago now ran into this NULL ptr passed to the merge_left() (internal) gpc library function, when trying to process dense (very detailed) data, but even after adding code 'protecting' against such a segfault, the resultant tile produced could not be displayed correctly by FG rendering engine. See the tile results here - http://geoffair.org/tmp/2892641.htm There were 2 types of 'bad' tiles, named by Cullam and I as (a) 'painters' Mondrian style, with parallel banding, and (b) 'spaghetti', where triangles cross each other in multiple layers... We suspected somewhere a 'short' is used instead of an 'int' counter, since it always seemed to happen when some component counts exceeded 65536 ;=(( But could NOT track it down... and anyway maybe this does not address the gpc library problem... However, Since there are now many scenery builders wanting to use the higher resolution data available, a fix at both levels, gpc polygon massaging, and fg rendering, would be VERY MUCH appreciated. Anything I can do to help... Regards, Geoff. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Tue, Apr 19, 2011 at 9:13 AM, Geoff McLane ubu...@geoffair.info wrote: Quite some time ago now ran into this NULL ptr passed to the merge_left() (internal) gpc library function, when trying to process dense (very detailed) data, but even after adding code 'protecting' against such a segfault, the resultant tile produced could not be displayed correctly by FG rendering engine. See the tile results here - http://geoffair.org/tmp/2892641.htm There were 2 types of 'bad' tiles, named by Cullam and I as (a) 'painters' Mondrian style, with parallel banding, and (b) 'spaghetti', where triangles cross each other in multiple layers... We suspected somewhere a 'short' is used instead of an 'int' counter, since it always seemed to happen when some component counts exceeded 65536 ;=(( But could NOT track it down... and anyway maybe this does not address the gpc library problem... Yup, this is definitely a problem. In order to keep file sizes down, the index into the vertex, normal, and texture coordinate lists is a short ... it might even be a signed short. So if the number of items exceeds 32767, then you will get indexing errors and all kinds of weirdness in the result. I think the code (at least as it appears now) has been updated to use unsigned int counters so this boosts us up to 65535, but beyond that you will have these sorts of problems. However, Since there are now many scenery builders wanting to use the higher resolution data available, a fix at both levels, gpc polygon massaging, and fg rendering, would be VERY MUCH appreciated. Anything I can do to help... Tradeoffs ... if we switch from short to int, we double the size of the section of the btg file that indexes back into all the vertex, normal, and texture coordinate arrays. With the world scenery already pushing 12Gb, this is a significant decision. Also we need to protect some backwards compatibility. The btg file format is versioned, so we could create a new version number and add code to handle the new format variant. Also when you push this many polygons through the render pipeline, know that you are going to grind a lot of people's machines to a halt. That's not necessarily a reason not to push more detail, just something to be aware of ... hardware is always getting faster of course. Any updates here would require compatible change between the terragear tool chain and the simgear btg loader. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Tue, 2011-04-19 at 09:29 -0500, Curtis Olson wrote: [] Yup, this is definitely a problem. In order to keep file sizes down, the index into the vertex, normal, and texture coordinate lists is a short ... it might even be a signed short. [] Tradeoffs ... if we switch from short to int, we double the size of the section of the btg file that indexes back into all the vertex, normal, and texture coordinate arrays. With the world scenery already pushing 12Gb, this is a significant decision. Also we need to protect some backwards compatibility. Hi Curt, I agree the 'public' world data size should not grow much beyond the current 12Gb, and we MUST maintain some backward compatibility, and that is why perhaps your BTG format presently starts with a (word) 'SG' signature ;=)) and a (word) version 6... There is no double people WANT to be able to generate scenery for the specific area they know and LOVE. It probably breaks their heart each time they fly over it and say to them selves where is that important turn in the river?, the little bay?, that small hill? (like the recent Rio comments), etc, etc, etc... So such a unsigned int BTG 'signature' certainly opens the way to have other 'versions' of the BTG file, as you suggest, and then users can be _WARNED_ it can only be generated by TG 2.3?, and loaded/viewed by SG/FG 2.3 plus... And they can further be warned that such a 'new' BTG file may indeed require 'better' hardware... raising the min. requirement... but machine power is forever increasing anyway... as you mention... Hmmm, while I thought I had researched EVERY counter, as you point out, in all cases I observed that is now an int, which gives us +/-2,147,483,647, which should be ok, but sort of forgot to look very closely at the index lists themselves ;=(( If these are shorts, or even unsigned shorts, then that is BIG trouble for high definition scenery... which can easily go beyond 65K indexes per tile... you can even do it now with modest raw data, but push terrafit to break up the DEM into a smaller elevation mesh... So are their others interested in going forward with a 'new' BTG? Let us hear from you... Who can help, do what? I know and read some, like Martin, want to go perhaps another direction, and that too is fine... but in the interim why not just 'extend' what we have? Regards, Geoff. PS: I remember someone, off list I think, mentioning that maybe the gpc library has been improved... must try to re-find that reference... there is also no doubt polygon clipping is integral to a new BTG format... -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: It is certainly good advice to optimize for the correct processor, but using unsupported instructions typically result in a SIGILL not a SIGSEGV. It would help to see the actual disassembly around the fault and machine register contents. It smells like alignment problem. Hi Jester, I can get that for you, if you want. But what do you need? info registers? The whole coredump file? Cheers, Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, Apr 18, 2011 at 12:16 PM, Christian Schmitt ch...@ilovelinux.de wrote: I can get that for you, if you want. But what do you need? info registers? The whole coredump file? Info registers, and something like x/10i $eip (or $rip on 64 bit) -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Csaba Halász wrote: Info registers, and something like x/10i $eip (or $rip on 64 bit) Here you go (still on Atom), Phenom this evening. (gdb) info registers eax0x0 0 ecx0xb7e67380 -1209633920 edx0x814aab0135572144 ebx0xb7fbfff4 -1208221708 esp0xbfffc4d8 0xbfffc4d8 ebp0xbfffc4e8 0xbfffc4e8 esi0x3 3 edi0xbfffc72c -1073756372 eip0xb7fb8fdd 0xb7fb8fdd merge_left+9 eflags 0x210286 [ PF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x/10i $eip = 0xb7fb8fdd merge_left+9: mov0x14(%eax),%eax 0xb7fb8fe0 merge_left+12: movl $0x1,0x4(%eax) 0xb7fb8fe7 merge_left+19: mov0x8(%ebp),%eax 0xb7fb8fea merge_left+22: mov0x14(%eax),%edx 0xb7fb8fed merge_left+25: mov0xc(%ebp),%eax 0xb7fb8ff0 merge_left+28: mov0x14(%eax),%eax 0xb7fb8ff3 merge_left+31: cmp%eax,%edx 0xb7fb8ff5 merge_left+33: je 0xb7fb9058 merge_left+132 0xb7fb8ff7 merge_left+35: mov0x8(%ebp),%eax 0xb7fb8ffa merge_left+38: mov0x14(%eax),%eax Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Mon, Apr 18, 2011 at 1:38 PM, Christian Schmitt ch...@ilovelinux.de wrote: Csaba Halász wrote: Info registers, and something like x/10i $eip (or $rip on 64 bit) Here you go (still on Atom), Phenom this evening. (gdb) info registers eax 0x0 0 (gdb) x/10i $eip = 0xb7fb8fdd merge_left+9: mov 0x14(%eax),%eax Hm, ok, that doesn't seem to be SSE related, it's just your everyday NULL pointer. Have to check source code to see how that can happen. -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: Here you go (still on Atom), Phenom this evening. Phenom: (gdb) bt #0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at gpc.c:785 #1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0, clip=0x770120, result=0x74edc0) at gpc.c:1383 #2 0x0045a3cb in polygon_clip (poly_op=POLY_UNION, subject=..., clip=...) at polygon.cxx:385 #3 0x0045a613 in tgPolygonUnion (subject=..., clip=...) at polygon.cxx:441 #4 0x0045337c in gen_taxiway (rwy_info=..., alt_m=25.29840087890625, material=..., rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180) at taxiway.cxx:103 #5 0x0040d61d in build_runway (rwy_info=..., alt_m=25.29840087890625, rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180, apt_base=0x7fffa220, apt_clearing=0x7fffa1d0) at build.cxx:300 #6 0x0040fbde in build_airport (airport_id=..., alt_m=25.2984009, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:614 #7 0x00444623 in main (argc=4, argv=0x7fffda68) at main.cxx:340 (gdb) info registers rax0x0 0 rbx0x3 3 rcx0x0 0 rdx0x7c4f30 8146736 rsi0x0 0 rdi0x7c4f00 8146688 rbp0x7fff8430 0x7fff8430 rsp0x7fff8430 0x7fff8430 r8 0x7506b0 7669424 r9 0x3 3 r100x7720def0 140737339514608 r110x206518 ---Type return to continue, or q return to quit--- r120x405540 4216128 r130x7fffda60 140737488345696 r140x0 0 r150x0 0 rip0x77bd4504 0x77bd4504 merge_left+20 eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/10i $rip = 0x77bd4504 merge_left+20: mov0x20(%rax),%rax 0x77bd4508 merge_left+24: movl $0x1,0x4(%rax) 0x77bd450f merge_left+31: mov-0x18(%rbp),%rax 0x77bd4513 merge_left+35: mov0x20(%rax),%rdx 0x77bd4517 merge_left+39: mov-0x20(%rbp),%rax 0x77bd451b merge_left+43: mov0x20(%rax),%rax 0x77bd451f merge_left+47: cmp%rax,%rdx 0x77bd4522 merge_left+50: je 0x77bd45a1 merge_left+177 0x77bd4524 merge_left+52: mov-0x18(%rbp),%rax 0x77bd4528 merge_left+56: mov0x20(%rax),%rax -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. On Mon, Apr 18, 2011 at 11:59 AM, Christian Schmitt ch...@ilovelinux.dewrote: Christian Schmitt wrote: Here you go (still on Atom), Phenom this evening. Phenom: (gdb) bt #0 0x77bd4504 in merge_left (p=0x7c4f00, q=0x0, list=0x7c4f30) at gpc.c:785 #1 0x77bd6861 in gpc_polygon_clip (op=GPC_UNION, subj=0x747fb0, clip=0x770120, result=0x74edc0) at gpc.c:1383 #2 0x0045a3cb in polygon_clip (poly_op=POLY_UNION, subject=..., clip=...) at polygon.cxx:385 #3 0x0045a613 in tgPolygonUnion (subject=..., clip=...) at polygon.cxx:441 #4 0x0045337c in gen_taxiway (rwy_info=..., alt_m=25.29840087890625, material=..., rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180) at taxiway.cxx:103 #5 0x0040d61d in build_runway (rwy_info=..., alt_m=25.29840087890625, rwy_polys=0x7fffb0b0, texparams=0x7fffb090, accum=0x7fffa180, apt_base=0x7fffa220, apt_clearing=0x7fffa1d0) at build.cxx:300 #6 0x0040fbde in build_airport (airport_id=..., alt_m=25.2984009, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:614 #7 0x00444623 in main (argc=4, argv=0x7fffda68) at main.cxx:340 (gdb) info registers rax0x0 0 rbx0x3 3 rcx0x0 0 rdx0x7c4f30 8146736 rsi0x0 0 rdi0x7c4f00 8146688 rbp0x7fff8430 0x7fff8430 rsp0x7fff8430 0x7fff8430 r8 0x7506b0 7669424 r9 0x3 3 r100x7720def0 140737339514608 r110x206518 ---Type return to continue, or q return to quit--- r120x405540 4216128 r130x7fffda60 140737488345696 r140x0 0 r150x0 0 rip0x77bd4504 0x77bd4504 merge_left+20 eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/10i $rip = 0x77bd4504 merge_left+20: mov0x20(%rax),%rax 0x77bd4508 merge_left+24: movl $0x1,0x4(%rax) 0x77bd450f merge_left+31: mov-0x18(%rbp),%rax 0x77bd4513 merge_left+35: mov0x20(%rax),%rdx 0x77bd4517 merge_left+39: mov-0x20(%rbp),%rax 0x77bd451b merge_left+43: mov0x20(%rax),%rax 0x77bd451f merge_left+47: cmp%rax,%rdx 0x77bd4522 merge_left+50: je 0x77bd45a1 merge_left+177 0x77bd4524 merge_left+52: mov-0x18(%rbp),%rax 0x77bd4528 merge_left+56: mov0x20(%rax),%rax -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. Curt, it's not a question of finishing this build, it's a fact that something is broken and I'd like to do my best to help get it fixed. FYI: I found another, different segfault with EGKK: Starting program: /usr/bin/genapts --input=./EGKK.dat --work=./test Input file = ./EGKK.dat Terrain sources = ./test/SRTM2-Africa-3 ./test/SRTM2-Australia-3 ./test/SRTM2-Eurasia-3 ./test/SRTM2-Islands-3 ./test/SRTM2-North_America-3 ./test/SRTM2-South_America-3 ./test/DEM-USGS-3 ./test/SRTM-1 ./test/SRTM-3 ./test/SRTM-30 Work directory = ./test Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data version = 810 Next airport = EGKK 196 End of file reached last_apt_id.length() = 4 Building EGKK Runway count = 0 Taxiway count = 1 w010n50/w001n51/2941771 Program received signal SIGSEGV, Segmentation fault. 0x0040fc55 in build_airport (airport_id=..., alt_m=0, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:621 621 taxiways[i].generated = true; (gdb) bt #0 0x0040fc55 in build_airport (airport_id=..., alt_m=0, runways_raw=..., beacons_raw=..., towers_raw=..., windsocks_raw=..., root=..., elev_src=...) at build.cxx:621 #1 0x00444e15 in main (argc=3, argv=0x7fffda68) at main.cxx:442 Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
The first fault is inside the gpc code. As I said before, by my best estimation, gpc is algorithmically correct, but when we throw arbitrary real world numerical data at it, we can encounter some numerical degeneracies and that can blow up the gpc routines. I have no complaints if someone wants to dive into gpc and make it more numerically stable, but that's beyond what I've ever wanted to tackle myself. I'm sure there are a few dumb bugs in the code, but at least for this particular issue, if you are hoping that the fix is a one or two line patch that fixes a dumb programming typo, I afraid that's not the case. You have to dive deep into the underworld of polygon clipping and numerical representation. You need to get down to the level where flipping one trailing bit in a floating point number is the difference between the algorithm being numerically stable, or things going degenerate. Because of the way things work with computer floating point numbers, after clipping one region against another, you can end up with artifacts like a zero area triangle or a boundary that goes out to a point, returns to the previous point, and then continues on. Things happen that you can't see with the naked eye until you zoom in with an electron microscope. The basic process is that terragear/genapts is creating a jigsaw puzzle out of a collection of almost arbitrary polygon data. The source data could overlap in any variety of ways (even by just a very very very tiny bit.) There could be cracks and gaps in the input data. We have to resolve questions like: what if a road, airport runway, and ocean area all want to occupy the same physical space (due to different data sets assembled with different standards of precision.) The end result can't have any slivers that are too small, and can't have any gaps or cracks. It needs to be topologically consistent. However, given the nature of the input data and the nature of ieee floating point numbers, this is not always possible to do. And as the input data gets more detailed, these problems are magnified. So my suggestion is to focus on how to maintain a topologically consistent numerical representation of arbitrary polygon data while performing arbitrary clipping and union functions to the pieces. That is where the problems will get cured. Hunting for a stray null pointer that some programmer inadvertently screwed up, or digging into gcc optimization routines might all be interesting, and you may just find some real problems that have been lurking, but you won't have addressed the core underlying issues that cause most of the problems with terragear. One possible solution would be to create a fine grid and map all the input data to our grid --- but there are some challenges with properly mapping an arbitrary polygon (out of some gis database) to our underlying grid. That can't be done perfectly so all kinds of special cases will need to be discovered the hard way and dealt with. Maybe we could create really fine mesh, and then paint each grid section based on the highest ranking polygon type that covers that grid. Maybe this could even be done in the form of a raster image? There are probably ways this could be done to avoid the polygon clipper problems, but none of these approaches would be trivial to implement and would bring their own unique challenges and problems that we'd have to discover the hard way through trial and error. And with all of this, I'd love for anyone to advance the discussion by jumping in with code that fixes the problems or new ways to do things that are better than the way we were doing things before ... or even evidence that proves me entirely wrong. I'm stating the way I understand things and the observations and evidence I have ... and my hope is that it lights a fire under someone to advance the discussion by proving me wrong or coming up with something better ... while simultaneously saving people from hunting for problems in fruitless areas. Best regards, Curt. On Mon, Apr 18, 2011 at 12:20 PM, Christian Schmitt wrote: Curtis Olson wrote: Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. Curt, it's not a question of finishing this build, it's a fact that something is broken and I'd like to do my best to help get it fixed. FYI: I found another, different segfault with EGKK: Starting program: /usr/bin/genapts --input=./EGKK.dat --work=./test Input file = ./EGKK.dat Terrain sources = ./test/SRTM2-Africa-3 ./test/SRTM2-Australia-3 ./test/SRTM2-Eurasia-3 ./test/SRTM2-Islands-3 ./test/SRTM2-North_America-3 ./test/SRTM2-South_America-3 ./test/DEM-USGS-3 ./test/SRTM-1 ./test/SRTM-3 ./test/SRTM-30 Work directory = ./test Nudge = 10 Longitude = -180:180 Latitude = -90:90 Data
Re: [Flightgear-devel] terragear-cs segfault
On Mon, 18 Apr 2011 19:20:59 +0200, Christian wrote in message 20110418172059.cd1fe1318...@mail.sigmos.de: Curtis Olson wrote: Right, as said before, you crashed inside the gpc code. Have you tried regenerating this airport using the --nudge option (increasing the value in small increments until you find a value that allows the airport to be successfully built.) Regards, Curt. Curt, it's not a question of finishing this build, it's a fact that something is broken and I'd like to do my best to help get it fixed. ..heeding Curt's hint on ' --nudge ', helps find a new way to crash it, which again means we get a little closer to a viable diagnosis on gpc. Without that, expect no fix. FYI: I found another, different segfault with EGKK: ..this will help, once we understand the bug, we can fix it. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: After that genapts segfaulted during EGKK processing and right until now I have still not much of a clue what exactly is going on. I thought it was a problem with compiling TG against SG and not SG-CS (all from GIT). That showed to be wrong. Next guess was overoptimization (-O2 and -march), yet unsetting this and recompiling did not solve it either. After recompiling simgear and terragear multiple times with different cflags i guess I found out what is the problem: the use of sse/sse2 instructions by gcc. Here is a diff output of the internal GCC options between a non-working config and a working one: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 -#define __FLT_EVAL_METHOD__ 0 +#define __FLT_EVAL_METHOD__ 2 #define __unix__ 1 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 @@ -51,7 +51,6 @@ #define __DEC32_MIN__ 1E-95DF #define __DBL_MAX_EXP__ 1024 #define __DEC128_EPSILON__ 1E-33DL -#define __SSE2_MATH__ 1 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WINT_T__ 4 @@ -73,7 +72,6 @@ #define __ELF__ 1 #define __FLT_RADIX__ 2 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L -#define __SSE_MATH__ 1 #define __SIZEOF_PTRDIFF_T__ 4 #define __DEC32_SUBNORMAL_MIN__ 0.01E-95DF #define __FLT_HAS_QUIET_NAN__ 1 I encountered this problem on an Atom-based machine and an AMD Phenom machine. So, yes, I should probably change my cflags in this case. But given many distros that will ship this as binary package (compiled with SSE instructions enabled), the better way would be to fix it in the code. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, 17 Apr 2011 14:02:02 +0200, Christian wrote in message 20110417120036.a62241318...@mail.sigmos.de: Christian Schmitt wrote: After that genapts segfaulted during EGKK processing and right until now I have still not much of a clue what exactly is going on. I thought it was a problem with compiling TG against SG and not SG-CS (all from GIT). That showed to be wrong. Next guess was overoptimization (-O2 and -march), yet unsetting this and recompiling did not solve it either. After recompiling simgear and terragear multiple times with different cflags i guess I found out what is the problem: the use of sse/sse2 instructions by gcc. Here is a diff output of the internal GCC options between a non-working config and a working one: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __DBL_DENORM_MIN__ 4.9406564584124654e-324 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 -#define __FLT_EVAL_METHOD__ 0 +#define __FLT_EVAL_METHOD__ 2 #define __unix__ 1 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 @@ -51,7 +51,6 @@ #define __DEC32_MIN__ 1E-95DF #define __DBL_MAX_EXP__ 1024 #define __DEC128_EPSILON__ 1E-33DL -#define __SSE2_MATH__ 1 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __SIZEOF_SIZE_T__ 4 #define __SIZEOF_WINT_T__ 4 @@ -73,7 +72,6 @@ #define __ELF__ 1 #define __FLT_RADIX__ 2 #define __LDBL_EPSILON__ 1.08420217248550443401e-19L -#define __SSE_MATH__ 1 #define __SIZEOF_PTRDIFF_T__ 4 #define __DEC32_SUBNORMAL_MIN__ 0.01E-95DF #define __FLT_HAS_QUIET_NAN__ 1 I encountered this problem on an Atom-based machine and an AMD Phenom machine. So, yes, I should probably change my cflags in this case. But given many distros that will ship this as binary package (compiled with SSE instructions enabled), the better way would be to fix it in the code. ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here? Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may be updating gcc-4.5 now if they didn't earlier this week, so it could well be the bug you've found, is being fixed, or has been fixed by now. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: -#define __FLT_EVAL_METHOD__ 0 +#define __FLT_EVAL_METHOD__ 2 I think a simple -O2 should be permitted. Does it still fail with setting just this single option ? I encountered this problem on an Atom-based machine and an AMD Phenom machine. So, yes, I should probably change my cflags in this case. But given many distros that will ship this as binary package (compiled with SSE instructions enabled), the better way would be to fix it in the code. If I understand correctly, what you're calling a fix would be a workaround to circumvent a compiler/platform bug in my terminology. Right !? ;-) Are you running an appropriate kernel on your platform ? As far as I remember, the Atom processor series is just a slightly modified and shrinked down Pentium III processor. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Martin Spott wrote: -#define __FLT_EVAL_METHOD__ 0 +#define __FLT_EVAL_METHOD__ 2 I think a simple -O2 should be permitted. Does it still fail with setting just this single option ? The O2 flag was set for all tries but it's not the problem here. The problem are certain -march options. -march=core2 -mfpmath=sse for the Atom showed the error. Settung it to a more conservative -march=prescott makes it work. In this case it was a clear overoptimization. But there are other march settings like -march=amdfam10 for my Phenom which enable SSE. If I understand correctly, what you're calling a fix would be a workaround to circumvent a compiler/platform bug in my terminology. Right !? ;-) Correct. Are you running an appropriate kernel on your platform ? As far as I remember, the Atom processor series is just a slightly modified and shrinked down Pentium III processor. My kernel is allright. If not i'd run into other issues already. Note that it's only EGKK where this happens. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Arnt Karlsen wrote: ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here? Where the problem lies in the code I don't know. But it would be SG or TG. My GCC version is 4.4.5, OS is Gentoo. Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may be updating gcc-4.5 now if they didn't earlier this week, so it could well be the bug you've found, is being fixed, or has been fixed by now. As I never encountered segfaults like this I currently think it's a SG/TG issue that was undetected until now. This does not mean that something has to be fixed as it's very small and can be circumvented by disabling SSE in the Makefile. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, 17 Apr 2011 16:08:35 +0200, Christian wrote in message 20110417140707.e067a1318...@mail.sigmos.de: Arnt Karlsen wrote: ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here? Where the problem lies in the code I don't know. But it would be SG or TG. ..aye, and it could be in gcc. I see sse, sse2 and sse3 mentioned several times in gcc-4.4:4.4.6-1's changelog since version 4.4.5. My GCC version is 4.4.5, OS is Gentoo. ..my gcc-4.4 is 4.4.6-1, OS is Debian Sid+Experimental: arnt@celsius:~/Documents$ dpkg -l |grep gcc |fmt -tu ii gcc 4:4.6.0-3exp1 The GNU C compiler ii gcc-4.3 4.3.5-5 The GNU C compiler ii gcc-4.3-base 4.3.5-5 The GNU Compiler Collection (base package) ii gcc-4.4 4.4.6-1 The GNU C compiler ii gcc-4.4-base 4.4.6-1 The GNU Compiler Collection (base package) ii gcc-4.5 4.5.2-9 The GNU C compiler ii gcc-4.5-base 4.5.2-9 The GNU Compiler Collection (base package) ii gcc-4.6 4.6.0-3 The GNU C compiler ii gcc-4.6-base 4.6.0-3 The GNU Compiler Collection (base package) ii gcc-4.6-doc 4.6-20110227-1 Documentation for the GNU compilers (gcc, gobjc, g++) ii gcc-4.6-locales 4.6.0-3 The GNU C compiler (native language support files) ii gcc-4.6-multilib 4.6.0-3 The GNU C compiler (multilib files) ii gcc-4.6-source 4.6.0-3 Source of the GNU Compiler Collection ii gcc-avr 1:4.3.5-1+b2 The GNU C compiler (cross compiler for avr) ii gcc-multilib 4:4.6.0-3exp1 The GNU C compiler (multilib files) ii gccgo-4.6 4.6.0-3 The GNU Go compiler ii gccgo-4.6-multilib 4.6.0-3 The GNU Go compiler (multilib files) ii gccxml 0.9.0+cvs20110222-1 XML output extension to GCC ii lib32gcc1 1:4.6.0-3 GCC support library (32 bit Version) ii libgcc1 1:4.6.0-3 GCC support library arnt@celsius:~/Documents$ Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may be updating gcc-4.5 now if they didn't earlier this week, so it could well be the bug you've found, is being fixed, or has been fixed by now. As I never encountered segfaults like this I currently think it's a SG/TG issue that was undetected until now. This does not mean that something has to be fixed as it's very small and can be circumvented by disabling SSE in the Makefile. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
I noticed the crash appeared to be in gpc.c. This is the general polygon clipping library code. I've spent a lot of time in that code and here are some things for people to be aware of: 1. I believe the code is algorithmically correct. 2. The problem is primarily binary floating point representation, rounding, and manipulating data values that as real values are unique, but as represented in a binary IEEE floating point format lead to various degeneracies. 3. When you process global GIS data, you encounter every possible unwelcome numerical situation. It is the nature of the beast. 4. A significant portion of the terragear code is dedicated to anticipating common problems and eliminating them before they proceed down the processing pipeline. There are many checks and tests and fixups that are run at various stages of the processing pipeline. 5. The airport generator makes extensive use of the GPC library too. 6. I introduced a nudge option to the genapts utility that would adjust the coordinates by millimeters -- not visually significant, but just enough to avoid whatever numerical blowup happened on a particular airport. 7. I've spent hundreds of hours if not a lot more investigating these issues and there's always a new one no matter what you do, and there's always a completely unexplainable one to be wrestled with. 8. Just when you think you've got it handled, someone introduces new GIS data or changes input data which creates a new numerically degenerate condition somewhere and we are back to hunting it down. The tool chain had some allowances for these inevitable numerical issues. Genapts could be restarted at any point in the database. You could run individual airports with the --nudge option to try to get past a problematic airport. The client-server tile building system carefully logged the output of each tile that was generated, so if a tile failed (a) you would know about it, and (b) there was quite a bit of debugging info logged so you could start investigating. The terragear-cs fork has had substantial changes from my original terragear tree. I've seen some cases where I thought some problems might have been introduced, and changes that maybe I didn't 100% agree with, along with some misunderstandings of the overall purpose. But the problem from my end is that the fork divergence happened at an incredibly stressful time of my life. I had just moved to a new house and taken on a bigger mortgage, a week later found out I was losing my job, had a horrible poor planning for taxes that year and came up impossibly short, not to mention some other family tragedy stuff that took a tremendous amount of our time and energy, even our dog died (that's maybe not a big thing in comparison, but then it ended up hitting us much harder than I every thought it would.) So the point is I let the fork happen, and let others take over management of terragear, because it was just far far beyond what I could handle thinking about at the time. Now we are where we are. I keep meaning one of these days to pull the terragear-cs code and all the newest on Martin's server and see if I can do a world build, but--- life seems to always get in the way of life. ;-) Anyway, hopefully that gives a little bit of context, and maybe a tip (--nudge=) to get past a crash in genapts. Regards, Curt. On Sun, Apr 17, 2011 at 9:08 AM, Christian Schmitt wrote: Arnt Karlsen wrote: ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here? Where the problem lies in the code I don't know. But it would be SG or TG. My GCC version is 4.4.5, OS is Gentoo. Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may be updating gcc-4.5 now if they didn't earlier this week, so it could well be the bug you've found, is being fixed, or has been fixed by now. As I never encountered segfaults like this I currently think it's a SG/TG issue that was undetected until now. This does not mean that something has to be fixed as it's very small and can be circumvented by disabling SSE in the Makefile. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload
Re: [Flightgear-devel] terragear-cs segfault
On Sun, 17 Apr 2011 16:04:17 +0200, Christian wrote in message 20110417140253.11d101318...@mail.sigmos.de: Martin Spott wrote: -#define __FLT_EVAL_METHOD__ 0 +#define __FLT_EVAL_METHOD__ 2 I think a simple -O2 should be permitted. Does it still fail with setting just this single option ? The O2 flag was set for all tries but it's not the problem here. The problem are certain -march options. -march=core2 -mfpmath=sse for the Atom showed the error. Settung it to a more conservative -march=prescott makes it work. ..you have no -march=atom ??? In this case it was a clear overoptimization. But there are other march settings like -march=amdfam10 for my Phenom which enable SSE. If I understand correctly, what you're calling a fix would be a workaround to circumvent a compiler/platform bug in my terminology. Right !? ;-) Correct. Are you running an appropriate kernel on your platform ? As far as I remember, the Atom processor series is just a slightly modified and shrinked down Pentium III processor. My kernel is allright. If not i'd run into other issues already. Note that it's only EGKK where this happens. ..you remind me of runaway Toyota's partnership with Microsoft, AFAIK, no road crash authority ever considered whether software bluescreens might turn off brakes at flat pedal power... ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Personal experience speaking here: Any time you run off to find a bug in gcc, or in a driver, or you think there' s a bug in the optimizer, or your operating system: STOP! These are all loud and bright flashing warnings for something stupid in your own code. If people want to spend hours chasing after phantoms in their compiler or their optimizer, that's fine, some people need to learn the hard way for themselves, and 1 out of 1000 times, maybe there is a compiler bug. But your time is much better spent hunting for the problem in our own code. I can guarantee you 99.99% reliably that is where it's at. Regards, Curt. On Sun, Apr 17, 2011 at 11:05 AM, Arnt Karlsen a...@c2i.net wrote: On Sun, 17 Apr 2011 16:08:35 +0200, Christian wrote in message 20110417140707.e067a1318...@mail.sigmos.de: Arnt Karlsen wrote: ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here? Where the problem lies in the code I don't know. But it would be SG or TG. ..aye, and it could be in gcc. I see sse, sse2 and sse3 mentioned several times in gcc-4.4:4.4.6-1's changelog since version 4.4.5. My GCC version is 4.4.5, OS is Gentoo. ..my gcc-4.4 is 4.4.6-1, OS is Debian Sid+Experimental: arnt@celsius:~/Documents$ dpkg -l |grep gcc |fmt -tu ii gcc 4:4.6.0-3exp1 The GNU C compiler ii gcc-4.3 4.3.5-5 The GNU C compiler ii gcc-4.3-base 4.3.5-5 The GNU Compiler Collection (base package) ii gcc-4.4 4.4.6-1 The GNU C compiler ii gcc-4.4-base 4.4.6-1 The GNU Compiler Collection (base package) ii gcc-4.5 4.5.2-9 The GNU C compiler ii gcc-4.5-base 4.5.2-9 The GNU Compiler Collection (base package) ii gcc-4.6 4.6.0-3 The GNU C compiler ii gcc-4.6-base 4.6.0-3 The GNU Compiler Collection (base package) ii gcc-4.6-doc 4.6-20110227-1 Documentation for the GNU compilers (gcc, gobjc, g++) ii gcc-4.6-locales 4.6.0-3 The GNU C compiler (native language support files) ii gcc-4.6-multilib 4.6.0-3 The GNU C compiler (multilib files) ii gcc-4.6-source 4.6.0-3 Source of the GNU Compiler Collection ii gcc-avr 1:4.3.5-1+b2 The GNU C compiler (cross compiler for avr) ii gcc-multilib 4:4.6.0-3exp1 The GNU C compiler (multilib files) ii gccgo-4.6 4.6.0-3 The GNU Go compiler ii gccgo-4.6-multilib 4.6.0-3 The GNU Go compiler (multilib files) ii gccxml 0.9.0+cvs20110222-1 XML output extension to GCC ii lib32gcc1 1:4.6.0-3 GCC support library (32 bit Version) ii libgcc1 1:4.6.0-3 GCC support library arnt@celsius:~/Documents$ Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may be updating gcc-4.5 now if they didn't earlier this week, so it could well be the bug you've found, is being fixed, or has been fixed by now. As I never encountered segfaults like this I currently think it's a SG/TG issue that was undetected until now. This does not mean that something has to be fixed as it's very small and can be circumvented by disabling SSE in the Makefile. Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization.
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: Martin Spott wrote: The O2 flag was set for all tries but it's not the problem here. The problem are certain -march options. -march=core2 -mfpmath=sse for the Atom showed the error. Settung it to a more conservative -march=prescott makes it work. In this case it was a clear overoptimization. Well, to be more precise, it's been optimization for an incompatible platfom ;-) The Core2 has a slightly different instruction set from the Pentium III, thus, if I were you, I'd let the 'native' compiler choose the right platform optimization for you - as long as you don't compile cross-platform. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, Apr 17, 2011 at 11:37 AM, Martin Spott wrote: Christian Schmitt wrote: Martin Spott wrote: The O2 flag was set for all tries but it's not the problem here. The problem are certain -march options. -march=core2 -mfpmath=sse for the Atom showed the error. Settung it to a more conservative -march=prescott makes it work. In this case it was a clear overoptimization. Well, to be more precise, it's been optimization for an incompatible platfom ;-) The Core2 has a slightly different instruction set from the Pentium III, thus, if I were you, I'd let the 'native' compiler choose the right platform optimization for you - as long as you don't compile cross-platform. Generally terragear is going to be more IO bound that compute bound anyway. I don't think you buy yourself a whole lot by trying to squeeze a few instructions savings into your build. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Martin Spott wrote: Well, to be more precise, it's been optimization for an incompatible platfom ;-) The Core2 has a slightly different instruction set from the Pentium III, thus, if I were you, I'd let the 'native' compiler choose the right platform optimization for you - as long as you don't compile cross-platform. I can agree, it was surely not the 100% correct setting. But for my Phenom I still have no clue what to do. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: [...] I'm trying not to add yet another iteration to the debate about the two terms topologically correct vs. good enough, everything's already been said (details upon request, if required), but I think one point ought to be made very clear in this context, for those who are unaware of the history of terragear-cs. The terragear-cs fork has had substantial changes from my original terragear tree. [...] So the point is I let the fork happen, and let others take over management of terragear, because it was just far far beyond what I could handle thinking about at the time. Stating that Curt let the fork happen could be quite misleading because people might understand that the fork would have been 'planned' in some way - which is entirely incorrect. Instead, the fork was actually nothing but the last resort after, within a period of ten !! months, Ralf Gerlich neither a) got a patch reviewed, which he had submitted to Curt nor b) was given write access to the TerraGear CVS repository. I _do_ acknowledge that Curt might have his very personal reasons for not considering Ralf's work then, but, let's be honest, what would _you_ do when you feel like being stuck in a dead end for such a long period as Ralf did, and would like to proceed in what you started ? Let me guess, I think you'd be creating a fork, and may it just be for the sole purpose of having your own development versioned. Nowadays people are creating their own public forks (ah, clones ;-) of terragear-cs before submitting _anything_ - which is't that bad at all - as long as they're planning to submit their changes sooner or later. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: Generally terragear is going to be more IO bound that compute bound anyway. I don't think you buy yourself a whole lot by trying to squeeze a few instructions savings into your build. Agreed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
It's good to get the view from both sides of the coin. :-) Hopefully the larger point to be made is that we are moving forward with terragear-cs and my main point of jumping in here is to try to give some context and hints and understanding of the basic system. There's no point in chasing down the wrong paths in search of bugs and work arounds. Regards, Curt. On Sun, Apr 17, 2011 at 1:49 PM, Martin Spott martin.sp...@mgras.netwrote: Curtis Olson wrote: [...] I'm trying not to add yet another iteration to the debate about the two terms topologically correct vs. good enough, everything's already been said (details upon request, if required), but I think one point ought to be made very clear in this context, for those who are unaware of the history of terragear-cs. The terragear-cs fork has had substantial changes from my original terragear tree. [...] So the point is I let the fork happen, and let others take over management of terragear, because it was just far far beyond what I could handle thinking about at the time. Stating that Curt let the fork happen could be quite misleading because people might understand that the fork would have been 'planned' in some way - which is entirely incorrect. Instead, the fork was actually nothing but the last resort after, within a period of ten !! months, Ralf Gerlich neither a) got a patch reviewed, which he had submitted to Curt nor b) was given write access to the TerraGear CVS repository. I _do_ acknowledge that Curt might have his very personal reasons for not considering Ralf's work then, but, let's be honest, what would _you_ do when you feel like being stuck in a dead end for such a long period as Ralf did, and would like to proceed in what you started ? Let me guess, I think you'd be creating a fork, and may it just be for the sole purpose of having your own development versioned. Nowadays people are creating their own public forks (ah, clones ;-) of terragear-cs before submitting _anything_ - which is't that bad at all - as long as they're planning to submit their changes sooner or later. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
I wrote: [...] Nowadays people are creating their own public forks (ah, clones ;-) of terragear-cs before submitting _anything_ - which is't that bad at all [...] This typo could be misleading as well :-) which isn't that bad at all is what I was trying to say, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: I can agree, it was surely not the 100% correct setting. But for my Phenom I still have no clue what to do. Does it fail even without _any_ additional compiler flag ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: Hopefully the larger point to be made is that we are moving forward with terragear-cs and my main point of jumping in here is to try to give some context and hints and understanding of the basic system. There's no point in chasing down the wrong paths in search of bugs and work arounds. Agreed - as well. Yet I think people should be aware that further devlopment in TerraGear is demanding much more than just fixing bugs in order to cope with the increasing detail in land cover. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, 17 Apr 2011 11:24:32 -0500, Curtis wrote in message BANLkTim3mv6zJ9bmDE1XRK=x1foslzg...@mail.gmail.com: Personal experience speaking here: Any time you run off to find a bug in gcc, or in a driver, or you think there' s a bug in the optimizer, or your operating system: STOP! These are all loud and bright flashing warnings for something stupid in your own code. If people want to spend hours chasing after phantoms in their compiler or their optimizer, that's fine, some people need to learn the hard way for themselves, and 1 out of 1000 times, maybe there is a compiler bug. But your time is much better spent hunting for the problem in our own code. I can guarantee you 99.99% reliably that is where it's at. ..a safe bet is update to the latest gcc-4.4 and gcc-4.5, I'm not that sure about gcc-4.6, AFAIK 4.6 is the default only for Debian Sid+Experimental (unstable+experimental), Debian.org's idea is find the bugs right there, and not somewhere costly. And, we have many more eyes looking there. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, 17 Apr 2011 19:41:31 + (UTC), Martin wrote in message ioffpb$ak4c$1...@osprey.mgras.de: Curtis Olson wrote: Hopefully the larger point to be made is that we are moving forward with terragear-cs and my main point of jumping in here is to try to give some context and hints and understanding of the basic system. There's no point in chasing down the wrong paths in search of bugs and work arounds. Agreed - as well. Yet I think people should be aware that further devlopment in TerraGear is demanding much more than just fixing bugs in order to cope with the increasing detail in land cover. Cheers, Martin. ..searching this list for TerrorGear will dig up the horror stories of its use too. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, Apr 17, 2011 at 2:56 PM, Arnt Karlsen a...@c2i.net wrote: ..searching this list for TerrorGear will dig up the horror stories of its use too. ;o) GIS on a global scale is a really really hard thing. There are tremendous challenges in terms of data set sizes, processing time, numerical representations, manipulating and crunching data, etc. Terrorgear is a clever play on words, but any one who is ready to dive in and create a better scenery system is more than welcome. The current system certainly has some limitations and I'd welcome updates that brought the system up to the next level of realism and polish ... or even replaced the current system entirely with something better. Sorry if I'm a little overly sensitive today to criticism ... even it it is wrapped in humor or cleverness... Just for the record: Terragear is a collection of unix utilities that can be arranged in a data processing pipeline with the final result being FlightGear scenery. The system is optimized for offline batch processing with a client/server arrangement so you can gang up an arbitrary number of clients all crunching chunks of scenery independently. It is not a graphical point and click system. People who have never seen unix before and are diving in expecting to be able to click next a couple times and have something useful pop out the other end 3 seconds later probably will be a little terrorized by what they find. But others who enjoy seeing dozens of machines cranking away in parallel on a task might have have fun with this. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
People who have never seen unix before and are diving in expecting to be able to click next a couple times and have something useful pop out the other end 3 seconds later probably will be a little terrorized by what they find. But others who enjoy seeing dozens of machines cranking away in parallel on a task might have have fun with this. Or help Gijs finishing TerraGearGUI 2.0! I have tested it on win32 and wow: I can build now my own sceneries much more easier! -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: GIS on a global scale is a really really hard thing. There are tremendous challenges in terms of data set sizes, processing time, numerical representations, manipulating and crunching data, etc. Terrorgear is a clever play on words, but any one who is ready to dive in and create a better scenery system is more than welcome. The current system certainly has some limitations and I'd welcome updates that brought the system up to the next level of realism and polish ... or even replaced the current system entirely with something better. Sorry if I'm a little overly sensitive today to criticism ... even it it is wrapped in humor or cleverness... I can only agree with you here, Curt. Everyone who has worked with GIS data knows that it can become very complex and time consuming to process. That we get scenery, now even from more complex data (although with errors and artefacts at some places) can be considered as a miracle, given the amount of development time TG receives, compared to FG/SG. I also have to say that the sourcecode of TG is nicely documented (i'm a complete noob when it comes to C/C++ programming) and yet I somehow can follow the logic in the code. That's why I'd like do dive deeper into the airport code and see if I can do something there. Building a frontend (Qt-based) as Gijs did, is a nice endeavour, but I hope the backend will not be forgotten and the audience will not have too elevated expectations. Cheers Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
On Sun, Apr 17, 2011 at 6:37 PM, Martin Spott martin.sp...@mgras.net wrote: Christian Schmitt wrote: Martin Spott wrote: The O2 flag was set for all tries but it's not the problem here. The problem are certain -march options. -march=core2 -mfpmath=sse for the Atom showed the error. Settung it to a more conservative -march=prescott makes it work. In this case it was a clear overoptimization. Well, to be more precise, it's been optimization for an incompatible platfom ;-) The Core2 has a slightly different instruction set from the Pentium III, thus, if I were you, I'd let the 'native' compiler choose the right platform optimization for you - as long as you don't compile cross-platform. It is certainly good advice to optimize for the correct processor, but using unsupported instructions typically result in a SIGILL not a SIGSEGV. It would help to see the actual disassembly around the fault and machine register contents. It smells like alignment problem. -- Csaba/Jester -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
