linux 问题 value too large for defined data type 解决方案

在共享文件夹下make文件的时候总是出错,错误提示为:Value too large for defined data type。在查阅了好多资料之后,发现是在mount出现了问题,如果安装了VMware Tools,也可能会在自动挂载的时候出现同样的错误。

解决办法:
在mount的时候加上“nounix,noserverino”参数
通过以下命令打开vmware-tools

cd /etc/init.d
vi vmware-tools

然后粘入以下代码(如果打开文件之后有类似的代码,将其覆盖即可)

# Mount all hgfs filesystems
vmware_mount_vmhgfs() {
  if [ "`is_vmhgfs_mounted`" = "no" ]; then
    if [ "`vmware_vmhgfs_use_fuse`" = "yes" ]; then
      mkdir -p $vmhgfs_mnt
      vmware_exec_selinux "$vmdb_answer_BINDIR/vmhgfs-fuse \
         -o subtype=vmhgfs-fuse,allow_other $vmhgfs_mnt"
    else
      vmware_exec_selinux "mount -t vmhgfs .host:/ $vmhgfs_mnt -o nounix,noserverino"
    fi
  fi
}

 

 

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
笔记本的风扇控制 ---------------------------------------- 09 November 2006. Summary of changes for version 20061109: 1) ACPI CA Core Subsystem: Optimized the Load ASL operator in the case where the source operand is an operation region. Simply map the operation region memory, instead of performing a bytewise read. (Region must be of type SystemMemory, see below.) Fixed the Load ASL operator for the case where the source operand is a region field. A buffer object is also allowed as the source operand. BZ 480 Fixed a problem where the Load ASL operator allowed the source operand to be an operation region of any type. It is now restricted to regions of type SystemMemory, as per the ACPI specification. BZ 481 Additional cleanup and optimizations for the new Table Manager code. AcpiEnable will now fail if all of the required ACPI tables are not loaded (FADT, FACS, DSDT). BZ 477 Added #pragma pack(8/4) to acobject.h to ensure that the structures in this header are always compiled as aligned. The ACPI_OPERAND_OBJECT has been manually optimized to be aligned and will not work if it is byte-packed. Example Code and Data Size: These are the sizes for the OS- independent acpica.lib produced by the Microsoft Visual C++ 6.0 32- bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size. Previous Release: Non-Debug Version: 78.1K Code, 17.1K Data, 95.2K Total Debug Version: 155.4K Code, 63.1K Data, 218.5K Total Current Release: Non-Debug Version: 77.9K Code, 17.0K Data, 94.9K Total Debug Version: 155.2K Code, 63.1K Data, 218.3K Total 2) iASL Compiler/Disassembler and Tools: Fixed a problem where the presence of the _OSI predefined control method within complex expressions could cause an internal compiler error. AcpiExec: Implemented full region support for multiple address spaces. SpaceId is now part of the REGION object. BZ 429 ---------------------------------------- 11 Oc
Version 1.7 ----------- - ADD: Delphi/CBuilder 10.2 Tokyo now supported. - ADD: Delphi/CBuilder 10.1 Berlin now supported. - ADD: Delphi/CBuilder 10 Seattle now supported. - ADD: Delphi/CBuilder XE8 now supported. - ADD: Delphi/CBuilder XE7 now supported. - ADD: Delphi/CBuilder XE6 now supported. - ADD: Delphi/CBuilder XE5 now supported. - ADD: Delphi/CBuilder XE4 now supported. - ADD: Delphi/CBuilder XE3 now supported. - ADD: Delphi/CBuilder XE2 now supported. - ADD: Delphi/CBuilder XE now supported. - ADD: Delphi/CBuilder 2010 now supported. - ADD: Delphi/CBuilder 2009 now supported. - ADD: New demo project FlexCADImport. - FIX: The height of the TFlexRegularPolygon object incorrectly changes with its rotation. - FIX: Added division by zero protect in method TFlexControl.MovePathSegment. - FIX: The background beyond docuemnt wasn't filled when TFlexPanel.DocClipping=True. - FIX: In "Windows ClearType" font rendering mode (OS Windows mode) the "garbage" pixels can appear from the right and from the bottom sides of the painted rectangle of the TFlexText object. - FIX: The result rectangle incorrectly calculated in the TFlexText.GetRefreshRect method. - FIX: Added FPaintCache.rcPaint cleanup in the TFlexPanel.WMPaint method. Now it is possible to define is the drawing take place via WMPaint or via the PaintTo direct call (if rcPaint contain non-empty rectangle then WMPaint in progress). - FIX: The TFlexPanel.FPaintCache field moved in the protected class section. Added rcPaint field in FPaintCache that represents drawing rectangle. - ADD: In the text prcise mode (TFlexText.Precise=True) takes into account the rotation angle (TFlexText.Angle). - FIX: Removed FG_NEWTEXTROTATE directive (the TFlexText Precise mode should be used instead). - FIX: The TFlexRegularPolygon object clones incorrectly drawed in case when TFlexRegularPolygon have alternative brush (gradient, texture). - ADD: Add TFlexPanel.InvalidateControl virtual method which calls from TFle
关于雷达方面的知识! EFFECTIVENESS OF EXTRACTING WATER SURFACE SLOPES FROM LIDAR DATA WITHIN THE ACTIVE CHANNEL: SANDY RIVER, OREGON, USA by JOHN THOMAS ENGLISH A THESIS Presented to the Department of Geography and the Graduate School of the University of Oregon in partial fulfillment of the requirements for the degree of Master of Science March 2009 11 "Effectiveness of Extracting Water Surface Slopes from LiDAR Data within the Active Channel: Sandy River, Oregon, USA," a thesis prepared by John Thomas English in partial fulfillment of the requirements for the Master of Science degree in the Department of Geography. This thesis has been approved and accepted by: Date Committee in Charge: W. Andrew Marcus, Chair Patricia F. McDowell Accepted by: Dean of the Graduate School © 2009 John Thomas English 111 IV An Abstract of the Thesis of John Thomas English in the Department of Geography for the degree of to be taken Master of Science March 2009 Title: EFFECTIVENESS OF EXTRACTING WATER SURFACE SLOPES FROM LIDAR DATA WITHIN THE ACTIVE CHANNEL: SANDY RIVER, OREGON, USA Approved: _ W. Andrew Marcus This paper examines the capability ofLiDAR data to accurately map river water surface slopes in three reaches of the Sandy River, Oregon, USA. LiDAR data were compared with field measurements to evaluate accuracies and determine how water surface roughness and point density affect LiDAR measurements. Results show that LiDAR derived water surface slopes were accurate to within 0.0047,0.0025, and 0.0014 slope, with adjusted R2 values of 0.35, 0.47, and 0.76 for horizontal intervals of 5, 10, and 20m, respectively. Additionally, results show LiDAR provides greater data density where water surfaces are broken. This study provides conclusive evidence supporting use ofLiDAR to measure water surface slopes of channels with accuracies similar to field based approaches. CURRICULUM VITAE NAME OF AUTHOR: John Thomas English PLACE OF BIRTH: Eugene, Oregon DATE OF BIRTH: January 1st, 1980 GRADUATE AND UNDERGRADUATE SCHOOLS ATTENDED: University of Oregon, Eugene, Oregon Southern Oregon University, Ashland, Oregon DEGREES AWARDED: Master of Science, Geography, March 2009, University of Oregon Bachelor of Science, Geography, 2001, Southern Oregon University AREAS OF SPECIAL INTEREST: Fluvial Geomorphology Remote Sensing PROFESSIONAL EXPERIENCE: LiDAR Database Coordinator, Oregon Department of Geology & Mineral Industries, June 2008 - present. LiDAR & Remote Sensing Specialist, Sky Research Inc., 2003 - 2008 GRANTS, AWARDS AND HONORS: Gamma Theta Upsilon Geographic Society Member, 2006 Gradutate Teaching Fellowship, Social Science Instructional Laboratory, 20062007 v VI ACKNOWLEDGMENTS I wish to express special thanks to Professors W.A. Marcus and Patricia McDowell for their assistance in the preparation of this manuscript. In addition, special thanks are due to Mr. Paul Blanton who assisted with field data collection for this project. I also thank the members ofmy family who have been encouraging and supportive during the entirety of my graduate schooling. I wish to thank my parents Thomas and Nancy English for always being proud of me. Special thanks to my son Finn for always making me smile. Lastly, special thanks to my wife Kathryn for her unwavering support, love, and encouragement. Dedicated to my mother Bonita Claire English (1950-2004). Vll V111 TABLE OF CONTENTS Chapter Page I. INTRODUCTION 1 II. BACKGROlTND 5 Water Surface Slope 5 LiDAR Measurements of Active Channel Features 7 III. STUDY AREA 10 IV. METHODS 22 Overview 22 LiDAR Data and Image Acquisition 23 Field Data Acquisition 24 LiDAR Processing 25 Calculation of Water Surface Slopes 27 Evaluating LiDAR Slope Accuracies and Controls 33 V. RESULTS 35 Comparison of Absolute Elevations from Field and LiDAR Data in Reach 1 35 Slope Comparisons 41 Surface Roughness Analysis 46 VI. DiSCUSSiON 51 VII. CONCLUSION 57 APPENDIX: ARCGIS VBA SCRIPT CODE 58 REFERENCES 106 IX LIST OF FIGURES Figure Page 1. Return Factor vs. LiDAR Scan Angle 2 2. Angle of Incidence 3 3. Wave Action Relationship to LiDAR Echo 3 4. Site Map 11 5. Annual Hydrograph of Sandy River 13 6. Oregon GAP Vegetation within Study Area 15 7. Photo of Himalayan Blackberry on Sandy River 16 8. Reach 1 Site Area Map with photo 18 9. Reach 2 Site Area Map 20 10. Reach 3 Site Area Map 21 11. LiDAR Point Filtering Processing Step 26 12. Field DEM Interpolated using Kriging 29 13. Reach 1 LiDAR Cross Sections and Sample Point Location 31 14. Differences Between LiDAR and Field Based Elevations 37 15. Regression ofLiDAR and Field Cross section Elevations 38 16. Comparison of LiDAR and Field Longitudinal Profiles (5, 10,20 meters) 40 17. Regression ofField and LiDAR Based Slopes (5, 10,20 meters) 42 18. Differences Between LiDAR and Field Based Slopes (5, 10,20 meters) 44 19. Relationship of Water Surfaces to LiDAR Point Density 47 20. Marmot Dam: Orthophotographyand Colorized Slope Model 50 21. LiDAR Point Density versus Interpolation 53 LIST OF TABLES T~k p~ 1. Reported Accuracies of 2006 and 2007 LiDAR 24 2. Results of LiDAR and Field Elevation Comparison 38 3. Results ofLiDAR and Field Slope Comparison (5, 10,20 meters) 45 4. Results of Reach 1 Slope Comparison 46 5. Water Surface Roughness Results for Reach 1,2, and 3 48 6. Results of Reach 1 Water Surface Roughness Comparison 49 7. Subset of Reach 3 Water Surface Roughness Analysis Near Marmot Dam 50 x 1 CHAPTER I INTRODUCTION LiDAR (Light Detection and Ranging) has become a common tool for mapping and documenting floodplain environments by supplying individual point elevations and accurate Digital Terrain Models (DTM) (Bowen & Waltermire, 2002; Gilvear et aI., 2004; Glenn et aI., 2005; Magid et aI., 2005; Thoma, 2005; Smith et aI., 2006; Gangodagamage et aI., 2007). Active channel characteristics that have been extracted using LiDAR include bank profiles, longitudinal profiles (Magid et aI., 2005; Cavalli et aI., 2007) and transverse profiles of gullies under forest canopies (James et aI., 2007). To date, however, no one has tested if LiDAR returns from water surfaces can be used to measure local water surface slopes within the active channel. Much of the reason that researchers have not attempted to measure water surface slopes with LiDAR is because most LiDAR pulses are absorbed or not returned from the water surface. However, where the angle of incidence is close to nadir (i.e. the LiDAR pulse is fired near perpendicular to water surface plane), light is reflected and provides elevations off the water surface (Figure 1, Maslov et aI., 2000). Where LiDAR pulses glance the water surface at angles of incidence greater than 53 degrees, a LiDAR pulse is 2 more often lost to refraction (Figure 2) (Jenkins, 1957). In broken water surface conditions the water surface plane is angled, which produces perpendicular angles of incidence allowing for greater chance of return (Maslov et al. 2000). Su et al. (2007) documented this concept by examining LiDAR returns off disturbed surfaces in a controlled lab setting (Figure 3). LiDAR returns off the water surface potentially provide accurate surface elevations that can be used to calculate surface slopes. 1.0 08 ~ 0.6 o t5 ~ E .2 ~ 04 02 00 000 __d=2° d=10 ° --d=200 --d=300 d=40o d=50o I I 2000 4000 60.00 sensing angle, degree I 8000 Figure 1. Return Factor vs. LiDAR Scan Angle. Figure shows relationship between water surface return and scan angle. Return Factor versus sensing angle at different levels of the waving d (d = scan angle). Figure shows the relationship of scan angle of LiDAR to return from a water surface. Return factor is greatest at low scan angles relative to the nadir region of scan. (Maslov, D. V. et. al. (2000). A Shore-based LiDAR for Coastal Seawater Monitoring. Proceedings ofEARSeL-SIGWorkshop, Figure 1, pg. 47). 3 reflected\\ :.;/ incident 1 I 1 . '\ I lAIR \ •••••••• ••••••••••••• •••••• ••••••••••••••••••••• • •• eo ••••••••••• o •••••••••••• _0 •••••••••• 0 ••• .•.•.•.•.•.•00 ,••••• ' 0•••• 0 ••••••••••• 0 ••I' .•.•.•.•.•.,................. .".0 ••••••••••••• , •••••••••••• , ••••••••••0••••. .....................................~ . ••••••••••••••••••••••••••••••••••••• • •••••••••••••••••••••••••• 0 •••••••••••••••••••• 0 ••••• 0 •• ~~~)}))}))})))))))))\..)}))?()))))))))))))))))j((~j< Figure 2. Angle of Incidence. Figure displays concept of reflection and refraction of light according to angle of incidence. The intensity of light is greater as the angle of incidence approaches nadir. (Jenkins, F.A., White, RE. "Fundamentals of Optics". McGraw-Hili, 1957, Chapter 25) 09 08 0.7 0.6 0.5 0.4 0.3 0.2 0.1 r - 0.\ O,j/6Y3- -500 17.5 35 52.5 70 horizonral scanning dislancC(lllm) 0.9 0.8 0.7 06 0.5 0.4 0.3 0.2 0.1 a b Figure 3. Wave Action Relationship to LiDAR Echo. "LiDAR measurements of wake profiles generated by propeller at 6000 rpm (a) and 8000 rpm (b). Su's work definitively showed LiDAR's ability to measure water surfaces, and the relationship of wave action to capability of echo. From Su (2007) figure 5, p.844 . This study examines whether LiDAR can accurately measure water surface elevations and slopes. In order to address this topic, I assess the vertical accuracy of LiDAR and the effects of water surface roughness on LiDAR within the active channel. Findings shed light on the utility of LiDAR for measuring water surface slopes in different stream environments and methodological constraints to using LiDAR for this purpose. 4 5 CHAPTER II BACKGROlJND Water Surface Slope Water surface slope is a significant component to many equations for modeling hydraulics, sediment transport, and fluvial geomorphic processes (Knighton, 1999, Sing & Zang, in press). Traditional methods for measuring water surface slope include both direct and indirect methods. Direct water surface slope measurements typically use a device such as a total station or theodolite in combination with a stadia rod or drop line to measure water surface elevations (Harrelson, et ai., 1994, Western et ai., 1997). Inaccuracies in measurements stem from surface turbulence that makes it difficult to precisely locate the water surface, especially in fast water where flows pile up against the measuring device (Halwas, 2002). Direct survey methods often require a field team to occupy several known points throughout a reach. This is a time consuming process, especially if one wanted to document water surface slope along large portions of a river. This method can be dangerous in deep or fast water. 6 Indirect methods of water surface slope measurement consist of acquiring approximate water surface elevations using strand lines, water marks, secondary data sources such as contours from topographic maps, or hydraulic modeling to back calculate the water depth (USACE, 1993; Western et aI., 1997). Variable quality of data and modeling errors can lead to inaccuracies using these methods. The use of strand lines and water marks may not necessarily represent the peak flows or the water surface. Contours may be calculated or interpolated from survey points taken outside the channel area. The most commonly used hydraulic models are based on reconstruction of I-dimensional flow within the channel and do not account for channel variability between cross section locations. LiDAR water surface returns have a great deal of promise for improving measurement of water surfaces in several significant ways. LiDAR measurements eliminate hazards associated with surveyors being in the water. LiDAR also captures an immense amount of elevation data over a very short period of time, with hundreds of thousands of pulses collected within a few seconds for a single swath. Within this mass of pulses, hundreds or thousands of measurements off the water's surface may be collected depending on the nature of surface roughness, with broken water surfaces increasing the likelihood of measurements (Figure 3). In addition, most terrestrial LiDAR surveys collect data by flying multiple overlapping flight lines, thus increasing the number of returns in off nadir overlapping areas and the potential for returns from water surfaces. 7 The accuracy of high quality LiDAR measurements is comparable to field techniques. The relative variability of quality LiDAR vertical measurements typically ranges between 0.03-0.05 meters (Leica, 2007), where relative variability is the total range of vertical error within an individual scan on surface of consistent elevation. Lastly, LiDAR has the ability to collect water surface elevations over large stretches of river within a single flight of a few hours. LiDAR Measurements of Active Channel Features Recent studies evaluating the utility of LiDAR in the active channel environment have documented the effectiveness of using LiDAR DTMs to extract bank profiles. Magid et al. (2005) examined long term changes of longitudinal profiles along the Colorado River in the Grand Canyon. The study used historical survey data from 1923 and differenced topographic elevations with LiDAR data flown in 2000. LiDAR with three meter spot spacing was used to estimate water surface profiles based on the LiDAR elevations nearest to the known channel. Cavalli et al. (2007) extracted longitudinal profiles of the exposed bed of the Rio Cordon, Italy using 0.5 meter LiDAR DEM cells. This study successfully attributed LiDAR DEM roughness within the channel to instream habitats. Bowen and Waltermire (2002) found that LiDAR elevations within the floodplain were less accurate than advertised by vendors and sensor manufacturers. Dense vegetation within the riparian area prevented LiDAR pulses from reaching the 8 ground surface resulting in accuracies ranging 1-2 meters. Accuracies within unvegetated areas and flat surfaces met vendor specifications (l5-20cm). James et al. (2007) used LiDAR at 3 meter spot spacing to map transverse profiles of gullies under forest canopies. Results from this study showed that gully morphologies were underestimated by LiDAR data, possibly due to low density point spacing and biased filtering of the bare earth model. Today, point densities of 4-8 points/m2 are common and would likely alleviate some of the troubles found in this study. Additional studies have used LiDAR to extract geomorphic data from channel areas. Schumann et al. (2008) compared a variety of remotely sensed elevation models for floodplain mapping. The study used 2 meter LiDAR DEMs as topographic base data for floodplain modeling, and found that modeled flood stages based on the LiDAR DEM were accurate to within 0.35m. Ruesser and Bierman (2007) used high resolution LiDAR data to calculate erosion fluxes between strath terraces based on elevation. Gangodagamage et al. (2007) used LiDAR to extract river corridor width series, which help to quantify processes involved in valley formation. This study used a fixed water surface elevation and did not attempt to demonstrate the accuracy of LiDAR derived water surfaces. Green LiDAR also has been used to examine riverine environments. Green LiDAR functions much like terrestrial LiDAR (which uses an infrared laser) except that green LiDAR systems use green light that has the ability to penetrate the water surface and measure the elevation of the channel bed. Green LiDAR is far less common than terrestrial LiDAR and the majority of studies have been centered on studies of ocean shorelines. Wang and Philpot (2007) assessed attenuation parameters for measuring bathymetry in near shore shallow water, concluding that quality bathymetric models can be achieved through a number of post-processing steps. Hilldale and Raft (2007) assessed the accuracy and precision of bathymetric LiDAR and concluded that although the resulting models were informative, bathymetric LiDAR was less precise than traditional survey methods. In general, it is often difficult to assess the accuracy of bathymetric LiDAR given issues related to access of the channel bed at time of flight. 9 10 CHAPTER III STUDY AREA The study area is the Sandy River, Oregon, which flows from the western slopes ofMount Hood northwest to the Columbia River (Figure 4). Recent LiDAR data and aerial photography capture the variety of water surface characteristics in the Sandy River, which range from shooting flow to wide pool-riffle formations. The recent removal of the large run-of-river Marmot Dam upstream of the analysis sites has also generated interest in the river's hydraulics and geomorphology. 11 545000 ,·......,c' 550000 556000 560000 Washington, I 565000 -. Portland Sandy River .Eugene Oregon 570000 ooo '~" ooo ~ ooo~ • Gresham (""IIIII/hill /flIt'r Oregon Clack. fna County Marmot Dam IHillshaded area represents 2006 LiDAR extent. Ol1hophotography was collected only along the Sandy River channel within the LiDAR extent. 10 KiiomElt:IS t---+---+-~I--+--+----t-+--+---+----jl 545000 550000 555000 560000 565000 570000 Figure 4. Site Map. Site area map showing location of analysis reaches within the 2006 and 2007 LiDAR coverage areas. Olihophotography was also collected for the 2006 study, but was collected only along the Sandy River channel. 12 Floodplain longitudinal slopes along the Sandy River average 0.02 and reach a maximum of 0.04. The Sandy River has closely spaced pool-riffles and rapids in the upper reaches, transitioning to longer sequenced pool-riffle morphology in the middle and lower reaches. The Sandy River bed is dominated by sand. Cobbles and small boulders are present mostly in areas of riffles and rapids. Much of the channel is incised with steep slopes along the channel boundaries. The flow regime is typical of Pacific Northwest streams, with peak flows in the winter months ofNovember through February and in late spring with snowmelt runoff (Figure 5). Low flows occur between late September and early October. The average peak annual flow at the Sandy River station below Bull Run River (USGS 14142500) is 106cms. Average annual low flow for the same gauge is 13.9cms. 13 USGS 14142500 SRNDY RIVER BL~ BULL RUN RIVER, NR BULL RUN, OR 200 k.===_~~~=~~~=.......==",,=~-........==~ ~....J Jan 01Feb Ollar 01Rpr O:t1ay 01Jun 01Jul 01Rug OJSep 010ct 01Nov O:IJec 01 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 \ 11 ~I\\ ,1\ 1\ j\ 1"J'fn I\. I, ) \ , ,;' ) I I" 'I'•., I I' I' ] 30000 ~~-~----~-------------~-------, o ~ 20000 ~ 8'-. 10000 ~ Ql Ql ~ U '001 ~ ::::J U, Ql to 1000 to .= u Co? '001 Cl )- .....J. a: Cl Hedian daily statistic <59 years) Daily nean discharge --- Estinated daily nean discharge Period of approved data Period of provisional data Figure 5, Annual Hydrograph of Sandy River. US Geological Survey gaging station annual hydrograph of Sandy River, Oregon at Bull Run River. Data from http://waterdata.usgs.gov/or/nwis/annual/ Vegetation is mostly a mixture of Douglas fir and western red hemlock (Figure 6). Other vegetation includes palustrine forest found in the upper portions of the study area, and agricultural lands found in the middle and lower portions. Douglas fir and western red hemlock make up 87% of vegetated areas, palustrine forest 5%, and agricultural lands 5%, the remaining 3% is open water associated with the channel and reservoirs (Oregon GAP Analysis Program, 2002). The city of Troutdale, OR abuts the lower reaches of the Sandy River. Along this stretch of river Himalayan blackberry, an invasive species, dominates the western banks (Figure 7). The presence of Himalayan blackberry is significant because LiDAR has trouble penetrating through the dense clusters of vines. When this blackberry is close to the water's edge it is difficult to accurately define the channel boundary. 14 15 545000 550000 555000 560000 565000 570000 Reach 3 10 !'<I':'ll1et-ars. I Oregon GAP Vegetation Washington 0 g 0 Ii: ~ Reach 1 I '~" ,. "~JO • Oregon Trout ale 0 0 0 8 00 '5"1 ~ g g '------' § I og l': 51 Agriculture Douglas Fir-W. Hemlock-W. Red Cedar Forest Grass-shrub-saplillg/Regeneratillg Forest Mixed Conifer/Mixed Deciduous Forest Open Water Palustrine Forest Red Alder-Big Leaf Maple Forest Urban oo o o~ 545000 550000 555000 560000 565000 570000 Figure 6. Oregon GAP Vegetation within Study Area. 1999 Oregon GAP Analysis data for Sandy River area. Map shows how the Sandy River area is dominated by Douglas fir forest with areas of palustrine forest and agricultural lands (Oregon Natural Heritage Program, 1999). 16 Figure 7. Photo of Himalayan Blackberry on Sandy River. Himalayan blackberry near mouth of the Sandy River March, 25th 2007. Photo by John English. This study focuses on three reaches of channel that represent a range of water surface conditions along the river. Reach 1 is a I80-m long pool-riffle reach located 3.7 river kilometers upstream from the mouth, and is where we collected field data shortly after the 2007 LiDAR flight (Figure 8a). The bed is sandy in this reach and can change dramatically during high flows. The bank full width of Reach 1 is approximately 108 meters at its widest point. At the downstream end of the riffle, the channel is constricted 17 by riprap placed along the banks as the river flows under a bridge. Vegetation comprises deciduous and conifer trees such as Douglas fir, hemlock, and cottonwoods. Blackberry is present along the channel, but is not so dense that it obscures the active channel boundary. 18 b. Figure 8. Reach 1 Site Area Map with Photo. Reach 1 site area. Top figure (a) shows approximate width at bank full and length of field data collections. Yellow circles represent points along stream margins where water surface elevations were surveyed. Bottom photo (b) looks downstream from total station location. 19 Reach 2 (Figure 9) is located approximately 23.5 kIn upstream from the mouth of the Sandy River and is 1,815 meters in length. The widest portion of channel at approximate bank full is 116m. The channel consists of a large meander with sinuosity of 1.38 and consists of six riffles and five pools spaced at regular intervals. The substrate consists of sands with small boulders and large cobbles dominating riffle areas. Cobbles and boulders have likely been introduced to the channel as a result of mass wasting. Douglas fir dominates along banks. 20 oJ> 0° 200 MetersO 0 ~~~~~~I O~~~OOO~ Figure 9. Reach 2 Site Area Map. Site map of Reach 2. Reach 2 contains 359 cross sections derived from LiDAR and 3,456 sample points. Inset map shows cross section sample locations derived from LiDAR and smooth/rough water surface delineations used in analysis. 21 Reach 3 is located 40.7km upstream from the mouth of the Sandy and is 2,815 meters in length (Figure 10). The widest portion of this section at approximate banle full is 88 meters. The upstream extent of the channel includes the supercritical flow of Marmot Dam. The channel is incised and relatively straight with a sinuosity of 1.08. Fine sands dominate the channel bed with some boulders likely present from mass wasting along valley walls. As with Reach 2, Douglas fir dominates bank vegetation along. 200 40) Inset mAp displays UDAR point I densily alol1g willl cross seellon Sanlpleing dala LiDAR cross section SAmple locations were used to eX1mcl poinl density values. 503 fOC I 000 '.1..Hrs 1-.,...--,.-+--=1..,=-,---4I--+-1---11 . Reach 3 Figure 10. Reach 3 Site Area Map. Site map of Reach 3. Inset map shows point LiDAR water surface points. Reach 3 contains 550 cross sections and 3,348 sample points. Visual examination of this map allows one to see how point density varies within the active channel. 22 CHAPTER IV METHODS Overview LiDAR data and orthophotography were collected in 2006 and additional LiDAR data were collected over the same area in 2007. Field measurements were obtained five days after the 2007 LiDAR flight in order to compare field measurements of water surface slope to LiDAR-based measurements. Time of flight field measurements of water surface elevations were not obtained for the 2006 flight, but the coincident collection of LiDAR data and orthophotos provide a basis for evaluating variability of LiDAR-based slopes over different channel types as identified from aerial photos. Following sections provide more detail regarding these methods. 23 LiDAR Data and Image Acquisition All LiDAR data were collected using a Leica ALS50 Phase II LiDAR system mounted on a Cessna Caravan C208 (see Table 1 for LiDAR acquisition specifications). The 2006 LiDAR data were collected October 2211d and encompassed 13,780 hectares of high resolution (2':4 points/m2 ) LiDAR data from the mouth of the Sandy River to Marmot Dam. Fifteen centimeter ground resolution orthophotography was collected September 26th , 2006 along the riparian corridor of the Sandy River from its mouth to just above the former site ofMarmot dam (Figure 4). The 2007 LiDAR were collected on October 8th and covered the same extent as the 2006 flight, but did not include orthophotography. Data included filtered XYZ ASCII point data, LiDAR DEMs as ESRI formatted grids at 0.5 meter cell size. Data were collected at 2':8 points per m2 providing a data set with significantly higher point density than the 2006 LiDAR data. The 2006 LiDAR data were collected in one continuous flight. 2006 orthophotography was collected using an RC30 camera system. Data were delivered in RGB geoTIFF format. LiDAR data were calibrated by the contractor to correct for IMU position errors (pitch, roll, heading, and mirror scale). Quality control points were collected along roads and other permanent flat features for absolute vertical correction of data. Horizontal accuracy ofLiDAR data is governed by flying height above ground with horizontal accuracy being equal to 1I3300th of flight altitude (meters) (Leica, 2007). 24 Table 1. Reported Accuracies of 2006 and 2007 LiDAR. Reported Accuracies and conditions for 2006 and 2007 LiDAR data. (Watershed Sciences PGE LiDAR Delivery Report, 2006, Watershed Sciences DOGAMI LiDAR Delivery Report, 2007). Relative Accuracy is a measure of flight line offsets resulting from sensor calibration. 2006 LiDAR 2007 LiDAR Flying height above ground level meters (AGL) 1100 1000 Absolute Vertical Accuracy in meters 0.063 0.034 Relative Accuracy in meters (calibration) 0.058 0.054 Horizontal Accuracy (l/3300th * AGL) meters 0.37 0.33 Discharge @ time of flight (cms) 13.05 20.8 - 21.8 LiDAR data collection over the Reach 1 field survey location was obtained in a single flight on October 8, 2007 between 1:30 and 6:00 pm. During the LiDAR flight, ground quality control data were collected along roads and other permanent flat surfaces within the collection area. These data were used to adjust for absolute vertical accuracy. Field Data Acquisition A river survey crew was dispatched at the soonest possible date (October 13, 2007) after the 2007 flight to collect ground truth data within the Reach 1. The initial aim was to survey water surface elevations at cross sections of the channel, but the survey was limited to near shore measurements due to high velocity conditions. We collected 187 measurements of bed elevation and depth one to fifteen meters from banks along both sides of the channel (Figure 8a) using standard total station longitudinal profile 25 survey methods (Harrelson, 1994). Seventy-six and 98 measurements were collected along the east and west banks, respectively, at intervals of approximately 1 to 2 meters. Thirteen additional measurements were collected along the east bank at approximately ten meter intervals. Depth measurements were added to bed elevations to derive water surface elevations. Discharge during the survey ranged between 22.5 and 22.7 cms during the survey of the east bank and remained steady at 22.5 cms during the survey of the west bank (USGS station 14142500). LiDAR Processing The goal ofLiDAR processing for this project was to classify LiDAR point data within the active channel as water and output this subset data for further analysis. The LiDAR imagery was first clipped to the active channel using a boundary digitized from the 2006 high resolution orthophotography. LiDAR point data were then reclassified to remove bars, banks, and overhanging vegetation (Figure 11). 26 Figure 11. LiDAR Point Filtering Processing Step. LiDAR processing steps. Top image shows entire LiDAR point cloud clipped to active channel boundary. Lower image shows the final processed LiDAR points representing only those points that reflect off the water surface. All bars and overhanging vegetation have been removed as well. 27 Water points were classified using the ground classification algorithm in Terrascan© (Soininen, 2005) to separate water surface returns from those off of vegetation or other surfaces elevated above the ground. The classification routine uses a proprietary mathematical model to accomplish this task. Once the ground classification was finished, classified points were visually inspected to add or remove false positives and remove in-channel features such as bar islands. A total of 11,593 of 1,854,219 LiDAR points were classified as water. Points classified as water were output as comma delimited x,y,z ASCII text files (XYZ), then converted to a 0.5 meter linearly interpolated ESRI formatted grid using ESRI geoprocessing model script. Calculation of Water Surface Slopes Water surface slopes were calculated using the rise over run dimensionless slope equation where the rise is the vertical difference between upstream and downstream water surface elevations and run is the longitudinal distance between elevation locations. LiDAR data is typically used in grid format. For this reason grid data were used for calculation of water surface slopes. We used linear interpolation to grid the LiDAR point data as this is the standard method used by the LiDAR contractor. In order to compare the LiDAR and field data it was also necessary to interpolate field 28 measurements to create a water surface for the entire stream. The field data-based DEM was created using kriging interpolation within ArcGIS Desktop Spatial Analyst (Figure 12). No quantitative analysis was performed to evaluate the interpolation method of the field-based water surface. The kriging interpolation was chosen because it producex the smoothest water surface based on visual inspection when compared to linear and natural neighbor interpolations, which generated irregular fluctuations that were unrealistic for a water surface. The kriged surface provided a water surface elevation model for comparative analysis with LiDAR. 29 Figure 12. Field DEM Interpolated using Kriging. Field DEM interpolated from field survey points using kriging method found in ArcGIS Spatial Analyst. DEM has been hiIlshaded to show surface characteristics. The very small differences in water surface elevations generate only slight variations in the hillshadeing. To compare LiDAR and field-based water surface slopes, water surface elevations from the LiDAR and field-based DEMS were extracted at the same locations along Reach I. To accomplish this, 37 cross sections were manually constructed at approximately Sm spacings (Figure 13). Cross sections comparisons were used rather than point-to-point comparisons between streamside field and LiDAR data points because the cross sections provide water surface slopes that are more representative of the entire channel. The Sm interval spacing was considered to be a sufficient for fine resolution slope extraction. Because cross section center points were used to calculate the longitudinal distance and because the stream was sinuous, the projection of the cross sections from the center line to the banks led to stream side distances between cross sections that differed from Sm. 30 31 Smooth 125 Meters I 100 I 75 I 50 I 25 I Cross Sections Cross Section Data Roughness Delineation Cross Section Sample Locations _ Rough oI ~ each 1 Figure 13. Reach 1 LiDAR Cross Sections and Sample Point Locations. Reach I LiDAR-derived cross section sample locations and areas of smooth and rough water surface delineations. 37 cross section and 444 sample points lie within Reach 1. 32 Cross sections were extracted using a custom ArcObjects VBA script (Appendix A). This script extracted 1 cell nearest neighbor elevations along the transverse cross sections at 5 meter intervals creating 444 cross section sample locations (Figure 13). Cross section averages were calculated using field-based and LiDAR-based elevation water surface grids. The average cross sectional elevation value for field and LiDAR data were then exported to Excel files, merged with longitudinal distance between cross section, and used to calculate field survey-based and LiDAR-based slopes between cross sections. Reaches 2 and 3, for which only LiDAR data were available, were sampled using the same cross sectional approach used in Reach 1. The data extracted from these reaches were used to characterize how LiDAR-based elevations, slopes and point densities interact with varying water surface roughness. Within Reach 2, 359 cross sections were drawn and elevations were sampled every five meters along each cross section creating 3,456 cross section sample locations (Figure 9). Reach 3 contained 550 cross sections and 3,348 cross section sample locations (Figure 10). Slopes were calculated between each cross section. 33 Evaluating LiDAR Slope Accuracies and Controls The accuracy of elevation data is the major control on slope accuracy, so a comparative analysis was performed using field survey and LiDAR elevations. First, field-based and LiDAR slopes were calculated at distance intervals of five, ten and twenty meters using average cross section elevations to test the sensitivity of the slopes to vertical inaccuracies in the LiDAR data. The field and LiDAR elevations were differenced using the same points used to create average cross section elevations. Differences were plotted in the form of histogram and cumulative frequency plot after transforming them into absolute values. Descriptive statistics were calculated to examine the range, minimum, maximum, and mean offset between data sets. Finally LiDAR and field-based values were compared using regression analysis. This study also examined the effects of water surface roughness on LiDAR elevation measurements, LiDAR point density, and LiDAR derived water surface slopes. Each reach was divided into smooth and rough sections based on visual analysis of the orthophoto data. One-meter resolution slope rasters were created from the LiDAR water surface grids using ArcGIS Spatial Analyst. One meter resolution point density grids were created from LiDAR point data (ArcGIS Spatial Analyst). Using the cross section sample points, values for water surface type, elevation, slope, and point density were extracted within each reach. Point sample data were transferred to tabular format, and average values were generated for each cross section. These tables were used to calculate 34 descriptive statistics associated with water surfaces such as elevation variance, average slope variance, average point density, and average slope. It is assumed in this study that smooth water surfaces are associated with pools and thus ought to have relatively low slopes. Conversely rough water surfaces are assumed to be representative of riffles and rapids, and thus ought to have relatively steeper slopes. Reach 1 contains field data, so slopes from LiDAR and field data were compared with respect to water surface conditions as determined from the aerial photos. 35 CHAPTER V RESULTS Results of this study encompass three analyses. Elevation analysis describes the statistical difference between LiDAR and field-based water surface elevations for Reach 1. Slope analysis compares LiDAR derived and field-based slopes calculated at 5, 10, and 20m longitudinal distances. These analyses aim to quantify both slope accuracy and slope sensitivity. Lastly, water surface analysis examines the relationship between LiDAR measured water surface slopes, point density, and water surface roughness. Comparison of Absolute Elevations from Field and LiDAR Data in Reach 1 The difference between water surface elevations from LiDAR affects the numerator within the rise over run equation, which in tum affects slope. This elevation analysis evaluation quantifies differences between field and LiDAR data. LiDAR-based cross section elevations were differenced from field-based cross section elevations. Difference values were examined through statistical analysis. 36 In terms of absolute elevations relative to sea level, the majority of LiDAR-based water surface elevations were lower than field-based elevations, although the LiDAR elevations were higher in the upper portion ofReach 1. Differences ranged between -0.04 and 0.05m with a mean absolute difference between field and LiDAR elevations of 0.02m (Figure 14 and Table 2). The range of differences is within the expected relative accuracies of LiDAR claimed by the LiDAR provider. Elevations for field and LiDAR data are significantly correlated with an R2 of 0.94 (Figure 15). The negative offset was expected given that discharge at time of LiDAR acquisition was lower than discharge at time of field data acquisition. Discharge during field acquisition ranged between 22.5 and 22.7 cfs, while discharge during LiDAR acquisition was between 20.8 and 21.8cfs. The portion of Reach 1 where LiDAR water surface measurements were higher than field measurements may be related to difference in discharge or change in bed configuration. Overall results showed that LiDAR data and field-based water surface measurements are comparable. 37 Distribution of Elevation Differences Between Field and LiDAR Water Surfaces 10 9 8 7 >. 6 u r:: ell 5 :l C'" ~ 4 u.. 3 2 0+---+ -0.05 -0.04 -0.03 -0.02 -0.01 0 0.01 0.02 0.03 0.04 0.05 More Elevation Difference, Field - L1DAR (m) Figure 14. Differences Between LiDAR and Field Based Elevations. Elevation difference statistics between cross sections derived from field and LiDAR elevation data. Positive differences indicate that field-based elevations were higher than LiDAR; negative differences indicate LiDAR elevations were higher. Values on x axis represent minimum difference within range. For example, the 0.01 category includes values ranging from 0.01 to 0.0199. y-1.18x-1.03 .... R2 =0.94 ""..,; I •• ./... ./ .- ./ • ./ • ./. /""I ./iI ../. _._~. -? , 38 Table 2. Results of LiDAR and Field Elevation Comparison. Descriptive and regression statistics for absolute difference lField - LiDARI values between cross section elevations. All units in meters. Sample size is 37. Mean 0.028 Median 0.030 Standard Deviation 0.013 Kurtosis -0.640 Skewness -0.484 Range of difference 0.093 Minimum difference 0.002 Absolute maximum difference 0.047 Confidence Level(95.0%) (m) 0.004 Elevation Comparison of Field and LiDAR Water Surface Elevations 5.72 5.70 ~_ 5.68 g 5.66 :0:; I1l 5.64 > iii 5.62 ell 5.60 () ~ 5.58 ~ 5.56 ~ 5.54 1\1 5.52 ~ IX 5.50 <C 5.48 o :J 5.46 5.44 5.42 5.46 5.48 5.50 5.52 5.54 5.56 5.58 5.60 5.62 5.64 5.66 5.68 5.70 Field Water Surface Elevation (m) Figure 15. Regression of LiDAR and Field Cross Section Elevations. Regression of field-based (x) and LiDAR-based (y) cross section elevations. 39 Comparison of longitudinal profiles offield and LiDAR water surfaces shows a clear relationship in overall shape (Figure 16), capturing similar trends in longitudinal profiles. Figure 16 shows field and LiDAR profiles become more similar in shape as distance between cross sections increases. In terms of overall shape, the greatest differences occur in the upper 30 m, where LiDAR-based profiles demonstrate a higher slope than do field-based measurements. Because of the five day lag between LiDAR and field measurements in this mobile bed stream, it is impossible to know the degree to which this difference represents error in measurements or real change in the system. 40 5 meter Longitudinal Profile Comparison 20 40 60 80 100 120 140 160 180 5.75 .s 5.70 ~" _ • •• • :. 5 <reter Field Profile II:: 5.65 ...- .=....:....:l..,... H.T• tI.:!..~.....~.Io-,•..-..;.....-.------j. 5rreterL,DARprof,lel- ..0.._. 5.60 .. • •• ~ 5.55 -1------------ .~•.~•.-.-.-------- ~ 5.50 +---------------"''-.--'~~ ~.. ,~ "yT1I:!'-'--- W 5.45 -1---------------.-::..---'.1-.........-- ...:I:C"IL'J-"---- 5.40 -t------,----,---------,----,------,----,---------,----,---------, o Longitudinal Distance Down Stream (m) A 10 meter Longitudinal Profile Comparison 5.75 5.70 . • [,.10 rreler Field Profile! I: I 5.65 • • , . • • • 10 rreter LiDAR Profile • • • I:: 5.60 • • 0 :;:; • • >Cll 5.55 • • ~ • • w 5.50 • • • • • • • • • 5.45 5.40 0 20 40 60 80 100 120 140 160 180 Longitudinal Distance Down Stream (m) B 20 meter Longitudinal Profile Comparison 5.75 5.70 • ,. 20 <reter Field Profile .s 5.65 • . • • • 20 rreler LiDARProfile • I:: 5.60 • 0 :;:; >Cll 5.55 •• Q) W 5.50 •• • , 5.45 . 5.40 0 20 40 60 80 100 120 140 160 180 Longitudinal Distance Down Stream (m) C Figure 16. Comparison of LiDAR and Field Longitudinal Profiles (5, 10, 20 meters). Longitudinal profiles of a) 5 meter, b) 10 meter, and c) 20 meter cross section elevations. 41 Slope Comparisons Slope in this study is calculated as the dimensionless ratio of rise over run. As noted in the Methods section, slopes were calculated over three different horizontal intervals to test the sensitivity of the LiDAR's internal relative accuracy. Differences in Sm LiDAR and field-based slopes derived from cross sections reveal substantial scatter (Figure l7a), although they clearly covary. Ten meter interval slopes show a stronger relationship (Figure 17b), while slopes based on cross sections spaced 20 m apart have the strongest relationship (Figure l7c). The slope associated with regression of field and LiDAR elevation data is not approximately 1 as one might expect. This is because LiDAR elevations are higher than field elevations at the upstream end of the reach, and lower at the downstream end. 42 5m Slope Comparison -c: ~ -0:: Q) (/l ~ ~.01 Q) C. .2 en 0:: « 0 ::i A -c: ~ 0:: --Q) (/l i2 -0.01 Q) C. 0 en 0:: « 0 ::i B 0.004 = 0.58x - 0.001 R2 = 0.38 ~.008 -0.008 Field Slope (Rise/Run) 10 meter Slope Comparison 0.004 y = 0.63x - 0.001 R2 = 0.51 -0.008 -0.008 Field Slope (Rise/Run) 20 meter Slope Comparison • 0.004 0.002 0.004 C :::l -0:: Q) (/l i2 ~.01 -Q) c. o Ci5 0:: « o~ 0.004 =0.66x - 0.001 R2 = 0.80 ~.008 ~.006 -0.008 Field Slope (Rise/Run) 0.002 0.004 C Figure 17. Regression of Field and LiDAR Based Slopes (5,10,20 meters). Scatter plots showing comparisons between slope values calculated at distance intervals of a) 5 meters, b) 10 meters, and c) 20 meters. 43 Figure 18 shows how the range of differences between LiDAR and field-based water surface slopes decrease as longitudinal distance increases. Five meter slope differences ranged between -0.004 and 0.004 (Figure 18a). Ten meter slope differences ranged between -0.002 and 0.003 (Figure 18b). Twenty meter slope differences ranged between 0 and 0.002 (Figure 18c). 44 Differences of Slope at 5m Between Field and LiDAR 10 » 8 0c Ql 6 :J 0" 4 .Q..l u. 2 0 SIll>< SIl"> SIll\- ~<::J <;:><::J <;:><::J SIl" ~ SIl" SIll\- SIl"> SIll>< ~/l, r;:,<::J ~'::; ~'::; ~'::; ~'::; ~o Slope Difference (Field-LiDAR) A Differences of Slope at 10m Between Field and L1DAR 7 6 ~ 5 lii 4 :J 0" 3 ~ u. 2 1 o +---+--~--;..J SIll>< ~<::J Slope Difference (Field-LiDAR) B Differences of Slope at 20m Between Field and LiDAR 4 ~~I\- ~~" ~ ~~" ~~I\- ~~"> ~~I>< o"/l, <;:>.~. ~.~.~.~. ~ Slope Difference (Field-LiDAR) o +---+--+--+--t- SIll>< SIl"> <;:><::J <;:><::J ~ 3 c Ql :J 2 0" ~ U. C Figure 18. Differences Between LiDAR and Field Based Slopes (5, 10,20 meters). Histogram charts showing difference values between field and LiDAR derived slopes at a) 5 meter slope distances, b) 10 meter slope distances, and c) 20 meter slope distances. 45 The mean difference between slopes decreases from 0.0017 to 0.0007 as slope distance interval is increased. Maximum slope difference and standard deviation of offsets decrease from 0.001 to 0.0005 and 0.0047 to 0.0014 respectively. Regression analysis of these data show a significant relationship for all three comparisons, and adjusted R2 increased from 0.357 to 0.763 with slope distance interval (Table 3). Table 3. Results of LiDAR and Field Slope Comparison (5, 10,20 meters). Descriptive and regression statistics for offsets between field and LiDAR derived slope values (Field minus LiDAR). Slope values are dimensionless rise / run. All data is significant at 0.01. Distance Interval 5m 10m 20m Mean 0.0017 0.0012 0.0007 Standard Deviation 0.0010 0.0007 0.0005 Range of Difference 0.0080 0.0047 0.0024 Minimum difference 0.0000 0.0000 0.0001 Maximum difference 0.0047 0.0026 0.0015 Count 36 16 8 Adjusted R squared 0.36 0.47 0.76 Water surface slope for the entire length of Reach 1 (l59.32m) was compared and yielded a difference of 0.0005. This difference is smaller (by 0.0002) than the difference between 20 meter slope (Table 4). Slope was calculated by differencing the most upstream and downstream cross sections and dividing by total length of reach. Differences between LiDAR and field-based slopes may represent real change due to the five day lag between data sets and difference in discharge. 46 Table 4. Results of Reach 1 Slope Comparison. Comparison of slopes calculated using the farthest upstream and downstream cross section elevation values. Slope values have dimensionless units stemming from rise over run. Upper Lower Reach Elevation (m) Elevation (m) Len2th (m) Slope Field 5.652 5.491 159.32 -0.0010 LiDAR 5.697 5.455 159.32 -0.0015 Surface Roughness Analysis Water surface condition was characterized as smooth or rough based on 2006 aerial photography (Figure 19). Surface roughness was examined to understand its effect on LiDAR data within the active channel, as well as LiDAR's ability to potentially capture difference in water surface turbulence. Table 5 shows statistics with relation to water surface condition for all three reaches. 47 Figure 19. Relationship of Water Surfaces to LiDAR Point Density. 2006 aerial photos were used to delineate rough and smooth water surfaces. Image on left shows a transition between rough water surface (seen as white water) and smooth water surface (seen as upstream pool). Image on right shows LiDAR point density in points per square meter. In all reaches point density, variance of elevations, and water surface slopes were significantly higher in rough surface conditions. These results indicate that LiDAR point density is directly related to the roughness of a water surface and that is capturing the rough water characteristics one would expect in areas where turbulence generates surface waves. 48 Table 5. Water Surface Roughness Results for Reach 1,2, and 3. Water surface statistical output for rough and smooth water surface of Reaches 1, 2, and 3. Results within table represent average values for each Reach. Slope values have dimensionless units from rise over run equation derived from ESRI generated slope grid. Point density values based on points/m2 • Elevation variance in meters. Reach 1 Reach 2 Reach 3 Rou~h water No. of Sample Points 153 1981 1968 Avg Slope -0.013 -0.011 -0.007 Point Density (pts/mL ) 1.195 1.002 1.217 Elevation Variance (m) 0.003 0.018 0.041 Smooth water No. of Sample Points 290 1474 1378 Avg Slope 0.0075 -0.0006 -0.0033 Point Density (pts/mL ) 0.149 0.550 0.480 Elevation Variance (m) 0.001 0.0077 0.024 Within Reach 1, cross section elevations were separated into rough and smooth water conditions and slopes were calculated using field and LiDAR data sets (Table 6). Again, results showed that rough water surfaces have greater slopes than smooth water surfaces. The smooth water surface of Reach 1 yielded a larger discrepancy between field and LiDAR derived slopes compared to rough water surface. This is because small differences between LiDAR and field elevations generate larger proportional error in the rise / run equation when total elevation differences between upstream and downstream are small. 49 Table 6. Results of Reach 1 Water Surface Roughness Comparison. Reach 1 water surface roughness slope analysis. Reach 1 was divided into smooth and rough water surfaces based upon visual characteristics present in aerial photography. Slopes were calculated for each area and compared with field data to examine accuracy. Surface Reach Upper Lower Slope Type Lenl!th (m) Elevation (m) Elevation (m) Slope Difference Field Smooth 83.11 5.652 5.642 -0.0001 N/A LiDAR Smooth 83.11 5.697 5.612 -0.0010 0.0009 Field Rough 71.73 5.635 5.491 -0.0020 N/A LiDAR Rough 71.73 5.592 5.455 -0.0019 -0.0001 Prior to collections of the 2007 data, Reach 3 contained the former Marmot Dam that was dismantled on October 19th , 2007 (Figure 20). The areas at and directly below the dam are rough water surfaces. The super critical flow at the dam yielded a slope of - 0.896 (Table 7). The run below the dam contained low slope values of less than -0.002. Both the dam fall and adjacent run yielded high point densities of greater than 2 points per square meter. 50 Cross Sections o Cross Section Sample Locations L1DAR derived Slope Model Value Higll 178814133 25 50 75 100 125 150 ~.',eters I I I I I I La,·, 0003936 Figure 20. Marmot Dam: Orthophotography and Colorized Slope Model. Mannot Dam at far upstream portion of Reach 3. Image on left shows dam site in 2006 orthophotography. Image on right shows the increase in slope associated with the dam. Marmot Dam was removed Oct. 19th , 2007. Table 7. Subset of Reach 3 Water Surface Roughness Analysis Near Marmot Dam. Subset of Reach 3 immediately surrounding Marmot Dam roughness analysis containing values for Mannot Dam. The roughness results fell within expectations showing increases in slope at the dam fall and high point densities at the dam fall and immediate down stream run. Habitat Type Avg Slope Point Density Point Density Variance Dam Fall -0.896 2.284 1.003 Dam Run -0.001 2.085 5.320 51 CHAPTER VI DISCUSSION The elevation analysis portion of this study shows that LiDAR can provide water surface profiles and slopes that are comparable to field-based data. The differences between LiDAR and field based measurements can be attributed to three potential sources. The first is the relative accuracy of the LiDAR data which has been reported between O.05m and O.06m by the vendor. The second source can be associated with the accuracy of field based measurements which are similar to the relative accuracy of the LiDAR (O.03m-O.05m). Lastly, the discharge differed between field data collection and LiDAR collection by O.02cms. It is possible that much of the O.05m difference observed through most of the Reach 1 profile (Figure 16) could be attributed to the difference in discharge and changes in bed configuration, but without further evidence, the degree of difference due to error or real change cannot be identified. Even if one attributes all the difference to error in LiDAR measurements, the overall correspondence ofLiDAR and field measurement (Figure 15 and 16) indicates that LiDAR-based surveys are useful for many hydrologic applications. 52 In the upper portion of the reach, the profiles display LiDAR elevations that are higher than the field data elevations, whereas the reverse is true at the base of the reach. This could be a function of difference in discharge between datasets, change in bed configuration, or an artifact of low point density. Low density of points forces greater lengths of interpolation between LiDAR points leading to a coarse DEM (Figure 21). Overall, the analysis Reach 1 profile indicates that LiDAR was able to match the fieldbased elevation measurements within ±O.05m. 53 Rough & Smooth Wa~t:e:-r~S~u=rf;:a~c:e:s~rz~~J,;~~ Grid Interpolation in Low Point Density Figure 21. LiDAR Point Density versus Interpolation. Side by side image showing long lines of interpolation associated with smooth water surfaces (right image). Smooth water surfaces tend to have low LiDAR point density. The image on the right shows a hillshade ofthe LiDAR DEM. The DEM has been visualized using a 2 standard deviation stretch to highlight long lines of interpolation. The comparability of LiDAR and field-based slopes showed a significant trend with increasing downstream distances between cross sections. Adjusted R2 values increased from 0.36 to 0.76 and the range of difference between field and LiDAR based slopes decreased from 0.0047 to 0.00 14 as longitudinal distance increased from 5 to 20- 54 m. This suggests that the 0.05m of expected variation of LiDAR derived water surface elevation has less effect on water surface slope accuracy as distance between elevation measurements points increases. Likewise, slopes accuracies along rivers with low gradients will improve as the longitudinal distance between elevation points increases. Overall, data has shown that LiDAR can measure water surface slopes with mean difference relative to field measurements of 0.017, 0.012, and 0.007 at horizontal distances of 5, 10, and 20 meters respectively. Although the discrepancy between field and LiDAR-based slopes is greatest at 5-m intervals, the overall slopes (Fig 17) and longitudinal profiles (Fig 16) even at this distance generally correspond. The use of a 5m interval water surface slope as a basis for comparison is really a worst case example, as water surface slopes are usually measured over longer reach scale distances where the discrepancy between LiDAR and field-based measurements is lower. The continuous channel coverage and accuracies derived from LiDAR represent a new level of accuracy and precision in terms of spatial extent and resolution of water surface slope measurements. Analysis of surface roughness found that rough water surfaces had significantly higher point densities than smooth water surfaces. Rough water surfaces averaged at least 1 point/m2 , while smooth water surfaces averaged less than 1 point/2m2 • Longitudinal profiles of Reach 1 indicate the most accurate water surface measurements occur in areas of higher point density (Fig. 16). Future applications that attempt to use 55 LiDAR to measure water surface slope ought to sample DEM elevations from high point density areas of channel. Water surface analysis also showed trends relating water surface roughness and slope. Rough water surfaces for all three analysis reaches averaged larger average slope values than smooth water surfaces. This is because rough water surfaces are commonly associated with steps, riffles, and rapids. All three of these habitat types are areas have higher slopes than smooth water habitats. Smooth water surfaces are commonly associated with pools or glides, which would be areas of lower slope. Future research should examine the potential for using LiDAR to characterize stream habitats based on in-stream point density and slope. This study is not without its limitations. The field area used to test the accuracy of LiDAR is only representative of a small portion of the Sandy River. Comparisons of field and LiDAR data would be improved by having mid-channel field data. One might also question the use of field based water surface slopes as control for measuring "accuracy". Water surface slope is difficult to measure for reasons stated earlier in this paper. One might make the argument that there is no real way to truly measure LiDAR accuracy of water surface slope, and that LiDAR and field based measurements are simply comparable. In this context, LiDAR holds an advantage over field based measurements given its ability to measure large sections of river in a single day. LiDAR has a distinct advantage over traditional methods of measurement in that measurements are returned from the water surface, and consequently not subject to errors 56 associated with variability of surface turbulence piling up against the measuring device. LiDAR can also capture long stretches of channel within a few seconds reducing the influence of changes in discharge. LiDAR data in general does have its limitations. LiDAR data are only as accurate as the instrumentation and vendor capabilities. LiDAR must be corrected for calibrations and GPS drift to create a reliable data set, and not all LiDAR vendors produce the same level of quality. LiDAR data may be more accurate in some river reaches than others. The study reaches of this study contained well defined open channels, which made identifying LiDAR returns off the water surface possible. Both LiDAR data sets were collected at low flows. Flows that are too low or channels that are too narrow may limit ability to extract water surface elevations because of protruding boulders or dense vegetation that hinders accurate measurements. In some cases vegetation within and adjacent to the channel may interfere with LiDAR's ability to reach the water surface. Researchers should consider flow, channel morphology, and biota when obtaining water surface slopes from LiDAR. 57 CHAPTER VII CONCLUSION This paper examined the ability of LiDAR data to accurately measure water surface slopes. This study has shown that LiDAR data provides sufficiently accurate elevation measurements within the active channel to accurately measure water surface slopes. Measurement of water surface slope with LiDAR provides researchers a tool which is both more efficient and cost effective in comparison with traditional field-based survey methods. Additionally, analysis showed that LiDAR point density is significantly higher in rough surface conditions. Water surface elevations should be gathered from high point density areas as low point density may hinder elevation accuracy. Channel morphology, gradient, flow, and biota should be considered when extracting water surface slopes as these attributes influence water surface measurement. Further study should examine accuracy of LiDAR derived water surface slopes in channel morphologies other than those in this study. Overall, the recognition that LiDAR can accurately measure water surface slopes allows researchers an unprecedented ability to study hydraulic processes for large stretches of river. Common: APPENDIX ARCGIS VBA SCRIPT CODE 58 Public g---.pStrmLayer As ILayer ' stream centerline layer selected by user (for step 1) Public g_StrearnLength As Double ' stream centerline length (for step 1) Public g_InputDistance As Integer 'As Double 'distance entered by user (for step 1) Public g_NumSegments As Integer I number of sample points entered by user (for step 1) Public gyPointLayer As ILayer I point layer created from stream centerline (for step 1) Public g]ntShpF1Name As String I point layer pathname (for step 1) Public gyMouseCursor As IMouseCursor 'mouse cursor Public g_LinearConverson As Double I linear conversion factor Public gyDEMLayer As IRasterLayer I DEM layer (for steps 3 and 4) Public g_DEMConvertUnits As Double I DEM vertical units conversion factor (for steps 3 and 4) Public g_MaxSearchDistance As Double 'maximum search distance (for step 4) Public L NumDirections As Integer I number of directions to search in (for step 4) Public g_SampleDistance As Double 'sample distance (for step 5) Public g_SampleNumber As Double ' total sample points (for step 5) Public g_VegBeginPoint As Boolean I where to start the calucaltion (for step 5) Public g_VegCaclMethod As Boolean 'which method for Vegetation Calculation (for step 5) Public gyContribLayer As ILayer ' contributing point layer (for step 6) Public gyReceivLayer As ILayer 'receiving point layer (for step 6) Public gyOutputLayerName As String I output shapefile (for step 6) Function VerifyField(fLayer As ILayer, fldName As String) As Boolean I verify that topo fields are in the stream centerline point layer Dim pFields As IFields Dim pField As IField Dim pFeatLayer As IFeatureLayer Dim pFeatClass As IFeatureClass Set pFeatLayer = fLayer Set pFeatClass = pFeatLayer.FeatureClass Set pFields = pFeatClass.Fields For i = 0 To pFields.FieldCount - 1 Set pField = pFields.Field(i) 'MsgBox pField.Name IfpField.Name = fldName Then VerifyField = True Exit Function End If Next VerifyField = False End Function Function Ca1cPointLatLong(inPnt As IPoint, inLayer As ILayer) As IPoint , in point layer Dim pFLayer As IFeatureLayer Set pFLayer = inLayer , spatial reference environment Dim pInSpatialRef As ISpatialReference Dim pOutSpatialRef As ISpatialReference Dim pGeoTrans As IGeoTransformation Dim pInGeoDataset As IGeoDataset Set pInGeoDataset = pFLayer Dim pSpatRefFact As ISpatialReferenceFactory , get map units of shapefile spatial reference Dim pPCS As IProjectedCoordinateSystem Set pPCS = pInGeoDataset.SpatialReference 'set spatial reference environment Set pSpatRefFact = New SpatialReferenceEnvironment Set pInSpatialRef= pInGeoDataset.SpatialReference 'MsgBox pInSpatialRef.Name Set pOutSpatialRef= pSpatRefFact.CreateGeographicCoordinateSystem(esriSRGeoCS_WGS1984) Set pGeoTrans = pSpatRefFact.CreateGeoTransformation(esriSRGeoTransformation_NADI983_To_WGS1984_1) Dim pOutGeom As IGeometry2 Set Ca1cPointLatLong = New Point Set CalcPointLatLong.SpatialReference = pInSpatialRef Ca1cPointLatLong.PutCoords inPnt.X, inPnt.Y Set pOutGeom = Ca1cPointLatLong pOutGeom.ProjectEx pOutSpatialRef, esriTransformForward, pGeoTrans, 0, 0, ° 'MsgBox inPnt.X &" "& inPnt.Y & vbCrLf& Ca1cPointLatLong.X &" "& Ca1cPointLatLong.Y End Function Sub OpenGxDialogO Dim pGxdial As IGxDialog Set pGxdial = New GxDialog pGxdial.ButtonCaption = "OK" pGxdial.Title = "Create Stream Centerline Point Shapefile" pGxdial.RememberLocation = True Dim pShapeFileObj As IGxObject Dim pGxFilter As IGxObjectFilter Set pGxFilter = New GxFilterShapefiles 'e.g shp Set pGxdial.ObjectFilter = pGxFilter If pGxdial.DoModaISave(ThisDocument.Parent.hWnd) Then Dim pLocation As IGxFile Dim fn As String 59 Set pLocation = pGxdial.FinalLocation fn = pGxdial.Name End If If Not pLocation Is Nothing Then LPntShpFlName = pLocation.Path & "\" & fn frmlB.tbxShpFileName.Text = g]ntShpFlName frmlB.cmdOK.Enabled = True End If End Sub Function GetAngle(pPolyline As IPolyline, dAlong As Double) As Double Dim pi As Double pi = 4 * Atn(l) Dim dAngle As Double Dim pLine As ILine Set pLine = New Line pPolyline.QueryTangent esriNoExtension, dAlong, False, 1, pLine , convert from radians to degrees dAngle = (180 * pLine.Angle) / pi I adjust angles , ESRI defines 0 degrees as the positive X-axis, increasing counter-clockwise I Ecology references 0 degrees as North, increasing clockwise If dAngle <= 90 Then GetAngle = 90 - dAngle Else GetAngle = 360 - (dAngle - 90) End If End Function Function FeatureExists(strFeatureFileName As String) As Boolean On Error GoTo ErrHandler: Dim pWSF As IWorkspaceFactory Set pWSF = New ShapefileWorkspaceFactory Dim pFeatWS As IFeatureWorksiJace Dim pFeatDS As IFeatureClass Dim strWorkspace As String Dim strFeatDS As String strWorkspace = SplitWorkspaceName(strFeatureFileName) & "\" strFeatDS = SplitFileName(strFeatureFileName) If PWSF.IsWorkspace(strWorkspace) Then Set pFeatWS = pWSF.OpenFromFile(strWorkspace, 0) Set pFeatDS = pFeatWS.OpenFeatureClass(strFeatDS) End If 60 FeatureExists = (Not pFeatDS Is Nothing) Set pWSF =Nothing Set pFeatWS = Nothing Set pFeatDS = Nothing Exit Function ErrHandler: FeatureExists = False End Function 'Returns a Workspace given for example C: \temp\dataset returns C:\temp Function SplitWorkspaceName(sWholeName As String) As String On Error GoTo ERH Dim pos As Integer pos = InStrRev(sWholeName, "\") If pos > 0 Then SplitWorkspaceName = Mid(sWholeName, 1, pos - 1) Else Exit Function End If Exit Function ERH: MsgBox "Workspace Split" & Err.Description End Function 'Returns a filename given for example C:\temp\dataset returns dataset Function SplitFileName(sWholeName As String) As String On Error GoTo ERH Dim pos As Integer Dim sT, sName As String pos = InStrRev(sWholeName, "\") Ifpos > 0 Then sT = Mid(sWholeName, 1, pos - 1) Ifpos = Len(sWholeName) Then Exit Function End If sName = Mid(sWholeName, pos + 1, Len(sWholeName) - Len(sT)) pos = InStr(sName, ".") If pos > 0 Then SplitFileName = Mid(sName, 1, pos - 1) Else SplitFileName = sName End If End If Exit Function ERH: 61 • MsgBox "Workspace Split:" & Err.Description End Function Public Sub BusyMouse(bolBusy As Boolean) 'Subroutine to change mouse cursor If g---'pMouseCursor Is Nothing Then Set g---'pMouseCursor = New MouseCursor End If IfbolBusy Then g---'pMouseCursor.SetCursor 2 Else g---'pMouseCursor.SetCursor 0 End If End Sub Function MakeColor(lRGB As Long) As IRgbColor Set MakeColor =New RgbColor MakeColor.RGB = lRGB End Function Function MakeDecoElement(pMarkerSym As IMarkerSymbol, _ dPos As Double)_ As ISimpleLineDecorationElement Set MakeDecoElement
Table of Contents Summary of gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Free Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Free Software Needs Free Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Contributors to gdb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 A Sample gdb Session . . . . . . . . . . . . . . . . . . . . . . 7 2 Getting In and Out of gdb . . . . . . . . . . . . . . . . 11 2.1 Invoking gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Choosing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Choosing Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 What gdb Does During Startup . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Quitting gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Logging Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 11 12 13 15 16 16 16 gdb Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Command Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4 Running Programs Under gdb . . . . . . . . . . . . . 25 4.1 Compiling for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Starting your Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Your Program’s Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Your Program’s Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Your Program’s Working Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Your Program’s Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Debugging an Already-running Process . . . . . . . . . . . . . . . . . . . . . . 4.8 Killing the Child Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Debugging Programs with Multiple Threads . . . . . . . . . . . . . . . . . . 4.10 Debugging Programs with Multiple Processes. . . . . . . . . . . . . . . . 4.11 Setting a Bookmark to Return to Later . . . . . . . . . . . . . . . . . . . . . 4.11.1 A Non-obvious Benefit of Using Checkpoints . . . . . . . . . . . . 5 25 26 28 28 29 29 30 31 31 34 36 37 Stopping and Continuing . . . . . . . . . . . . . . . . . . 39 5.1 Breakpoints, Watchpoints, and Catchpoints . . . . . . . . . . . . . . . . . . 5.1.1 Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Setting Watchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 Setting Catchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Deleting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 40 45 47 49 ii Debugging with gdb 5.1.5 Disabling Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6 Break Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.7 Breakpoint Command Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.8 “Cannot insert breakpoints” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.9 “Breakpoint address adjusted...” . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Continuing and Stepping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Stopping and Starting Multi-thread Programs . . . . . . . . . . . . . . . . 6 Examining the Stack . . . . . . . . . . . . . . . . . . . . . . 61 6.1 6.2 6.3 6.4 7 Stack Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backtraces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting a Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information About a Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 62 64 65 Examining Source Files . . . . . . . . . . . . . . . . . . . 67 7.1 Printing Source Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Specifying a Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Editing Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Choosing your Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Searching Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Specifying Source Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Source and Machine Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 49 50 52 53 53 54 57 59 67 68 69 69 70 70 72 Examining Data . . . . . . . . . . . . . . . . . . . . . . . . . . 75 8.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Ambiguous Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Program Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Artificial Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Output Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Examining Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Automatic Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8 Print Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.9 Value History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.10 Convenience Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.11 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.12 Floating Point Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.13 Vector Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.14 Operating System Auxiliary Information . . . . . . . . . . . . . . . . . . . . 8.15 Memory Region Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1.1 Memory Access Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1.2 Memory Access Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.1.3 Data Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.15.2 Memory Access Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.16 Copy Between Memory and a File . . . . . . . . . . . . . . . . . . . . . . . . . . 8.17 How to Produce a Core File from Your Program . . . . . . . . . . . . . 75 76 77 79 79 81 82 84 90 90 92 93 94 94 94 95 95 96 96 96 96 97 iii 8.18 Character Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.19 Caching Data of Remote Targets . . . . . . . . . . . . . . . . . . . . . . . . . . 100 8.20 Search Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9 C Preprocessor Macros . . . . . . . . . . . . . . . . . . 103 10 Tracepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 10.1 Commands to Set Tracepoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Create and Delete Tracepoints . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 Enable and Disable Tracepoints . . . . . . . . . . . . . . . . . . . . . . . 10.1.3 Tracepoint Passcounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.4 Tracepoint Action Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.5 Listing Tracepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.6 Starting and Stopping Trace Experiments . . . . . . . . . . . . . 10.2 Using the Collected Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 tfind n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 tdump. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 save-tracepoints filename . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Convenience Variables for Tracepoints . . . . . . . . . . . . . . . . . . . . . 11 Debugging Programs That Use Overlays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 11.1 11.2 11.3 11.4 12 107 107 108 108 109 110 110 111 111 113 114 114 How Overlays Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overlay Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Overlay Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overlay Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 116 118 119 Using gdb with Different Languages . . . . . 121 12.1 Switching Between Source Languages . . . . . . . . . . . . . . . . . . . . . . 12.1.1 List of Filename Extensions and Languages . . . . . . . . . . . . 12.1.2 Setting the Working Language . . . . . . . . . . . . . . . . . . . . . . . . 12.1.3 Having gdb Infer the Source Language . . . . . . . . . . . . . . . . 12.2 Displaying the Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Type and Range Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.1 An Overview of Type Checking . . . . . . . . . . . . . . . . . . . . . . . 12.3.2 An Overview of Range Checking . . . . . . . . . . . . . . . . . . . . . . 12.4 Supported Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1 C and C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.1 C and C++ Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.2 C and C++ Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.3 C++ Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.4 C and C++ Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.5 C and C++ Type and Range Checks . . . . . . . . . . . . . . 12.4.1.6 gdb and C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.7 gdb Features for C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1.8 Decimal Floating Point format . . . . . . . . . . . . . . . . . . . 12.4.2 Objective-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 121 122 122 122 123 123 124 125 125 126 127 128 129 129 129 130 131 131 iv Debugging with gdb 12.4.2.1 Method Names in Commands . . . . . . . . . . . . . . . . . . . . 12.4.2.2 The Print Command With Objective-C . . . . . . . . . . . 12.4.3 Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.3.1 Fortran Operators and Expressions . . . . . . . . . . . . . . . 12.4.3.2 Fortran Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.3.3 Special Fortran Commands . . . . . . . . . . . . . . . . . . . . . . 12.4.4 Pascal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5 Modula-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.1 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.2 Built-in Functions and Procedures . . . . . . . . . . . . . . . . 12.4.5.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.4 Modula-2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.5 Modula-2 Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.5.6 Deviations from Standard Modula-2 . . . . . . . . . . . . . . 12.4.5.7 Modula-2 Type and Range Checks . . . . . . . . . . . . . . . 12.4.5.8 The Scope Operators :: and . . . . . . . . . . . . . . . . . . . . 12.4.5.9 gdb and Modula-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6 Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.2 Omissions from Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.3 Additions to Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.6.4 Stopping at the Very Beginning . . . . . . . . . . . . . . . . . . 12.4.6.5 Known Peculiarities of Ada Mode . . . . . . . . . . . . . . . . 12.5 Unsupported Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 132 132 132 133 133 133 133 133 135 136 136 138 138 138 139 139 139 139 140 141 143 143 143 13 Examining the Symbol Table . . . . . . . . . . . . 145 14 Altering Execution . . . . . . . . . . . . . . . . . . . . . 151 14.1 14.2 14.3 14.4 14.5 14.6 15 Assignment to Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Continuing at a Different Address . . . . . . . . . . . . . . . . . . . . . . . . . Giving your Program a Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Returning from a Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calling Program Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patching Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 152 153 153 154 154 gdb Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 15.1 Commands to Specify Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 15.2 Debugging Information in Separate Files . . . . . . . . . . . . . . . . . . . 163 15.3 Errors Reading Symbol Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 16 Specifying a Debugging Target . . . . . . . . . . 169 16.1 Active Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 16.2 Commands for Managing Targets . . . . . . . . . . . . . . . . . . . . . . . . . . 170 16.3 Choosing Target Byte Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 v 17 Debugging Remote Programs . . . . . . . . . . . 173 17.1 Connecting to a Remote Target . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Sending files to a remote system . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3 Using the gdbserver Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3.1 Running gdbserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3.1.1 Attaching to a Running Program . . . . . . . . . . . . . . . . . 17.3.1.2 Multi-Process Mode for gdbserver . . . . . . . . . . . . . . . 17.3.1.3 Other Command-Line Arguments for gdbserver . . 17.3.2 Connecting to gdbserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3.3 Monitor Commands for gdbserver . . . . . . . . . . . . . . . . . . . . 17.4 Remote Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5 Implementing a Remote Stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.1 What the Stub Can Do for You . . . . . . . . . . . . . . . . . . . . . . . 17.5.2 What You Must Do for the Stub . . . . . . . . . . . . . . . . . . . . . . 17.5.3 Putting it All Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 173 175 175 175 176 176 177 177 177 178 181 182 183 184 Configuration-Specific Information . . . . . . . 185 18.1 Native. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.1 HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.2 BSD libkvm Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.3 SVR4 Process Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.4 Features for Debugging djgpp Programs . . . . . . . . . . . . . . 18.1.5 Features for Debugging MS Windows PE Executables . . 18.1.5.1 Support for DLLs without Debugging Symbols . . . . 18.1.5.2 DLL Name Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.5.3 Working with Minimal Symbols . . . . . . . . . . . . . . . . . . 18.1.6 Commands Specific to gnu Hurd Systems . . . . . . . . . . . . . 18.1.7 QNX Neutrino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2 Embedded Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1 Using gdb with VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1.1 Connecting to VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1.2 VxWorks Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1.3 Running Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3 Embedded Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.1 ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.2 Renesas M32R/D and M32R/SDI . . . . . . . . . . . . . . . . . . . . . 18.3.3 M68k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.4 MIPS Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.5 OpenRISC 1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.6 PowerPC Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.7 HP PA Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8 Tsqware Sparclet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.1 Setting File to Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.2 Connecting to Sparclet . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.3 Sparclet Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.8.4 Running and Debugging . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.9 Fujitsu Sparclite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.10 Zilog Z8000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 185 185 185 187 189 190 190 191 192 194 194 194 195 195 196 196 196 198 199 199 201 203 204 204 204 205 205 205 205 205 vi Debugging with gdb 18.3.11 Atmel AVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.12 CRIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.13 Renesas Super-H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4 Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.1 x86 Architecture-specific Issues . . . . . . . . . . . . . . . . . . . . . . . 18.4.2 A29K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.3 Alpha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.4 MIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.5 HPPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.4.6 Cell Broadband Engine SPU architecture . . . . . . . . . . . . . . 18.4.7 PowerPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Controlling gdb . . . . . . . . . . . . . . . . . . . . . . . . 211 19.1 19.2 19.3 19.4 19.5 19.6 19.7 19.8 20 206 206 207 207 207 207 207 208 209 209 210 Prompt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Editing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Screen Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Current ABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optional Warnings and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . Optional Messages about Internal Happenings . . . . . . . . . . . . . . 211 211 211 213 214 214 215 217 Canned Sequences of Commands . . . . . . . . 221 20.1 20.2 20.3 20.4 User-defined Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User-defined Command Hooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commands for Controlled Output . . . . . . . . . . . . . . . . . . . . . . . . . 221 222 223 224 21 Command Interpreters . . . . . . . . . . . . . . . . . . 227 22 gdb Text User Interface . . . . . . . . . . . . . . . . . 229 22.1 22.2 22.3 22.4 22.5 23 TUI Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI Key Bindings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI Single Key Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI-specific Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TUI Configuration Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 230 231 231 233 Using gdb under gnu Emacs . . . . . . . . . . . . 235 vii 24 The gdb/mi Interface . . . . . . . . . . . . . . . . . . . 237 Function and Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notation and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3 gdb/mi Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3.1 gdb/mi Input Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3.2 gdb/mi Output Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.4 gdb/mi Compatibility with CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.5 gdb/mi Development and Front Ends . . . . . . . . . . . . . . . . . . . . . 24.6 gdb/mi Output Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.6.1 gdb/mi Result Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.6.2 gdb/mi Stream Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.6.3 gdb/mi Async Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.7 Simple Examples of gdb/mi Interaction. . . . . . . . . . . . . . . . . . . . 24.8 gdb/mi Command Description Format . . . . . . . . . . . . . . . . . . . . 24.9 gdb/mi Breakpoint Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.10 gdb/mi Program Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.11 gdb/mi Thread Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.12 gdb/mi Program Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.13 gdb/mi Stack Manipulation Commands . . . . . . . . . . . . . . . . . . 24.14 gdb/mi Variable Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.15 gdb/mi Data Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.16 gdb/mi Tracepoint Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.17 gdb/mi Symbol Query Commands . . . . . . . . . . . . . . . . . . . . . . . 24.18 gdb/mi File Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.19 gdb/mi Target Manipulation Commands . . . . . . . . . . . . . . . . . 24.20 gdb/mi File Transfer Commands . . . . . . . . . . . . . . . . . . . . . . . . . 24.21 Miscellaneous gdb/mi Commands . . . . . . . . . . . . . . . . . . . . . . . . 25 gdb Annotations . . . . . . . . . . . . . . . . . . . . . . . 293 25.1 25.2 25.3 25.4 25.5 25.6 25.7 26 237 237 237 237 238 240 240 240 240 241 241 242 243 244 251 254 255 261 265 271 277 277 280 283 287 288 What is an Annotation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Server Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Annotation for gdb Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invalidation Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running the Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 294 294 294 295 295 296 Reporting Bugs in gdb . . . . . . . . . . . . . . . . . . 297 26.1 Have You Found a Bug? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 26.2 How to Report Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 viii Debugging with gdb 27 Command Line Editing . . . . . . . . . . . . . . . . . 301 27.1 Introduction to Line Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2 Readline Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.1 Readline Bare Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.2 Readline Movement Commands . . . . . . . . . . . . . . . . . . . . . . . 27.2.3 Readline Killing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.4 Readline Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2.5 Searching for Commands in the History . . . . . . . . . . . . . . . 27.3 Readline Init File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.3.1 Readline Init File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.3.2 Conditional Init Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . 27.3.3 Sample Init File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4 Bindable Readline Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.1 Commands For Moving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.2 Commands For Manipulating The History . . . . . . . . . . . . . 27.4.3 Commands For Changing Text . . . . . . . . . . . . . . . . . . . . . . . 27.4.4 Killing And Yanking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.5 Specifying Numeric Arguments . . . . . . . . . . . . . . . . . . . . . . . 27.4.6 Letting Readline Type For You . . . . . . . . . . . . . . . . . . . . . . . 27.4.7 Keyboard Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.4.8 Some Miscellaneous Commands . . . . . . . . . . . . . . . . . . . . . . . 27.5 Readline vi Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 301 301 301 302 302 303 303 304 304 309 310 313 313 313 315 316 317 317 317 318 319 Using History Interactively . . . . . . . . . . . . . . 321 28.1 History Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.1.1 Event Designators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.1.2 Word Designators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.1.3 Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 321 321 322 Appendix A Formatting Documentation . . . . 325 Appendix B Installing gdb . . . . . . . . . . . . . . . . 327 B.1 B.2 B.3 B.4 B.5 Requirements for Building gdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invoking the gdb ‘configure’ Script . . . . . . . . . . . . . . . . . . . . . . . Compiling gdb in Another Directory . . . . . . . . . . . . . . . . . . . . . . . Specifying Names for Hosts and Targets . . . . . . . . . . . . . . . . . . . . ‘configure’ Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix C 327 327 329 330 330 Maintenance Commands . . . . . . 333 ix Appendix D gdb Remote Serial Protocol . . . 339 D.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.2 Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.3 Stop Reply Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.4 General Query Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.5 Register Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.6 Tracepoint Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.7 Host I/O Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.8 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10 File-I/O Remote Protocol Extension . . . . . . . . . . . . . . . . . . . . . . D.10.1 File-I/O Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.2 Protocol Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.3 The F Request Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.4 The F Reply Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.5 The ‘Ctrl-C’ Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.6 Console I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.7 List of Supported Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lseek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . unlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . stat/fstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . gettimeofday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . isatty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.8 Protocol-specific Representation of Datatypes . . . . . . . . . Integral Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pointer Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Memory Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . struct stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . struct timeval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.9 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mode t Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Errno Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lseek Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.10.10 File-I/O Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.11 Library List Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.12 Memory Map Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 340 347 348 358 358 360 362 362 363 363 363 364 364 365 365 365 366 367 367 367 368 368 369 369 370 370 370 371 371 371 372 372 372 373 373 373 373 374 374 374 375 376 x Debugging with gdb Appendix E The GDB Agent Expression Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 E.1 E.2 E.3 E.4 E.5 E.6 General Bytecode Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bytecode Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Agent Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Varying Target Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tracing on Symmetrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix F 377 379 383 384 384 386 Target Descriptions . . . . . . . . . . . 389 F.1 Retrieving Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2 Target Description Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.1 Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.2.5 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.3 Predefined Target Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4 Standard Target Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.1 ARM Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.2 MIPS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.3 M68K Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F.4.4 PowerPC Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 390 390 390 391 391 391 392 393 393 393 394 394 Appendix G GNU GENERAL PUBLIC LICENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION . . . . . . . . . . . . . . . . . . . 396 How to Apply These Terms to Your New Programs . . . . . . . . . . . . . . . 400 Appendix H GNU Free Documentation License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 H.1 ADDENDUM: How to use this License for your documents . . 407 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 1 Summary of gdb The purpose of a debugger such as gdb is to allow you to see what is going on “inside” another program while it executes—or what another program was doing at the moment it crashed. gdb can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act: • Start your program, specifying anything that might affect its behavior. • Make your program stop on specified conditions. • Examine what has happened, when your program has stopped. • Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another. You can use gdb to debug programs written in C and C++. For more information, see Section 12.4 [Supported Languages], page 125. For more information, see Section 12.4.1 [C and C++], page 125. Support for Modula-2 is partial. [Modula-2], page 133. For information on Modula-2, see Section 12.4.5 Debugging Pascal programs which use sets, subranges, file variables, or nested functions does not currently work. gdb does not support entering expressions, printing values, or similar features using Pascal syntax. gdb can be used to debug programs written in Fortran, although it may be necessary to refer to some variables with a trailing underscore. gdb can be used to debug programs written in Objective-C, using either the Ap- ple/NeXT or the GNU Objective-C runtime. Free Software gdb is free software, protected by the gnu General Public License (GPL). The GPL gives you the freedom to copy or adapt a licensed program—but every person getting a copy also gets with it the freedom to modify that copy (which means that they must get access to the source code), and the freedom to distribute further copies. Typical software companies use copyrights to limit your freedoms; the Free Software Foundation uses the GPL to preserve these freedoms. Fundamentally, the General Public License is a license which says that you have these freedoms and that you cannot take these freedoms away from anyone else. Free Software Needs Free Documentation The biggest deficiency in the free software community today is not in the software—it is the lack of good free documentation that we can include with the free software. Many of our most important programs do not come with free reference manuals and free introductory texts. Documentation is an essential part of any software package; when an important free software package does not come with a free manual and a free tutorial, that is a major gap. We have many such gaps today. 2 Debugging with gdb Consider Perl, for instance. The tutorial manuals that people normally use are non-free. How did this come about? Because the authors of those manuals published them with restrictive terms—no copying, no modification, source files not available—which exclude them from the free software world. That wasn’t the first time this sort of thing happened, and it was far from the last. Many times we have heard a GNU user eagerly describe a manual that he is writing, his intended contribution to the community, only to learn that he had ruined everything by signing a publication contract to make it non-free. Free documentation, like free software, is a matter of freedom, not price. The problem with the non-free manual is not that publishers charge a price for printed copies—that in itself is fine. (The Free Software Foundation sells printed copies of manuals, too.) The problem is the restrictions on the use of the manual. Free manuals are available in source code form, and give you permission to copy and modify. Non-free manuals do not allow this. The criteria of freedom for a free manual are roughly the same as for free software. Redistribution (including the normal kinds of commercial redistribution) must be permitted, so that the manual can accompany every copy of the program, both on-line and on paper. Permission for modification of the technical content is crucial too. When people mod- ify the software, adding or changing features, if they are conscientious they will change the manual too—so they can provide accurate and clear documentation for the modified program. A manual that leaves you no choice but to write a new manual to document a changed version of the program is not really available to our community. Some kinds of limits on the way modification is handled are acceptable. For example, requirements to preserve the original author’s copyright notice, the distribution terms, or the list of authors, are ok. It is also no problem to require modified versions to include notice that they were modified. Even entire sections that may not be deleted or changed are acceptable, as long as they deal with nontechnical topics (like this one). These kinds of restrictions are acceptable because they don’t obstruct the community’s normal use of the manual. However, it must be possible to modify all the technical content of the manual, and then distribute the result in all the usual media, through all the usual channels. Otherwise, the restrictions obstruct the use of the manual, it is not free, and we need another manual to replace it. Please spread the word about this issue. Our community continues to lose manuals to proprietary publishing. If we spread the word that free software needs free reference manuals and free tutorials, perhaps the next person who wants to contribute by writing documentation will realize, before it is too late, that only free manuals contribute to the free software community. If you are writing documentation, please insist on publishing it under the GNU Free Documentation License or another free documentation license. Remember that this deci- sion requires your approval—you don’t have to let the publisher decide. Some commercial publishers will use a free license if you insist, but they will not propose the option; it is up to you to raise the issue and say firmly that this is what you want. If the publisher you are dealing with refuses, please try other publishers. If you’re not sure whether a proposed license is free, write to [email protected]. 3 You can encourage commercial publishers to sell more free, copylefted manuals and tutorials by buying them, and particularly by buying copies from the publishers that paid for their writing or for major improvements. Meanwhile, try to avoid buying non-free documentation at all. Check the distribution terms of a manual before you buy it, and insist that whoever seeks your business must respect your freedom. Check the history of the book, and try to reward the publishers that have paid or pay the authors to work on it. The Free Software Foundation maintains a list of free documentation published by other publishers, at http://www.fsf.org/doc/other-free-books.html. Contributors to gdb Richard Stallman was the original author of gdb, and of many other gnu programs. Many others have contributed to its development. This section attempts to credit major contrib- utors. One of the virtues of free software is that everyone is free to contribute to it; with regret, we cannot actually acknowledge everyone here. The file ‘ChangeLog’ in the gdb distribution approximates a blow-by-blow account. Changes much prior to version 2.0 are lost in the mists of time. Plea: Additions to this section are particularly welcome. If you or your friends (or enemies, to be evenhanded) have been unfairly omitted from this list, we would like to add your names! So that they may not regard their many labors as thankless, we particularly thank those who shepherded gdb through major releases: Andrew Cagney (releases 6.3, 6.2, 6.1, 6.0, 5.3, 5.2, 5.1 and 5.0); Jim Blandy (release 4.18); Jason Molenda (release 4.17); Stan Shebs (release 4.14); Fred Fish (releases 4.16, 4.15, 4.13, 4.12, 4.11, 4.10, and 4.9); Stu Grossman and John Gilmore (releases 4.8, 4.7, 4.6, 4.5, and 4.4); John Gilmore (releases 4.3, 4.2, 4.1, 4.0, and 3.9); Jim Kingdon (releases 3.5, 3.4, and 3.3); and Randy Smith (releases 3.2, 3.1, and 3.0). Richard Stallman, assisted at various times by Peter TerMaat, Chris Hanson, and Richard Mlynarik, handled releases through 2.8. Michael Tiemann is the author of most of the gnu C++ support in gdb, with significant additional contributions from Per Bothner and Daniel Berlin. James Clark wrote the gnu C++ demangler. Early work on C++ was by Peter TerMaat (who also did much general update work leading to release 3.0). gdb uses the BFD subroutine library to examine multiple object-file formats; BFD was a joint project of David V. Henkel-Wallace, Rich Pixley, Steve Chamberlain, and John Gilmore. David Johnson wrote the original COFF support; Pace Willison did the original support for encapsulated COFF. Brent Benson of Harris Computer Systems contributed DWARF 2 support. Adam de Boor and Bradley Davis contributed the ISI Optimum V support. Per Bothner, Noboyuki Hikichi, and Alessandro Forin contributed MIPS support. Jean-Daniel Fekete contributed Sun 386i support. Chris Hanson improved the HP9000 support. Noboyuki Hikichi and Tomoyuki Hasei contributed Sony/News OS 3 support. David Johnson con- tributed Encore Umax support. Jyrki Kuoppala contributed Altos 3068 support. Jeff Law contributed HP PA and SOM support. Keith Packard contributed NS32K support. 4 Debugging with gdb Doug Rabson contributed Acorn Risc Machine support. Bob Rusk contributed Harris Nighthawk CX-UX support. Chris Smith contributed Convex support (and Fortran de- bugging). Jonathan Stone contributed Pyramid support. Michael Tiemann contributed SPARC support. Tim Tucker contributed support for the Gould NP1 and Gould Powern- ode. Pace Willison contributed Intel 386 support. Jay Vosburgh contributed Symmetry support. Marko Mlinar contributed OpenRISC 1000 support. Andreas Schwab contributed M68K gnu/Linux support. Rich Schaefer and Peter Schauer helped with support of SunOS shared libraries. Jay Fenlason and Roland McGrath ensured that gdb and GAS agree about several machine instruction sets. Patrick Duval, Ted Goldstein, Vikram Koka and Glenn Engel helped develop remote debugging. Intel Corporation, Wind River Systems, AMD, and ARM contributed remote debugging modules for the i960, VxWorks, A29K UDI, and RDI targets, respectively. Brian Fox is the author of the readline libraries providing command-line editing and command history. Andrew Beers of SUNY Buffalo wrote the language-switching code, the Modula-2 sup- port, and contributed the Languages chapter of this manual. Fred Fish wrote most of the support for Unix System Vr4. He also enhanced the command-completion support to cover C++ overloaded symbols. Hitachi America (now Renesas America), Ltd. H8/500, and Super-H processors. sponsored the support for H8/300, NEC sponsored the support for the v850, Vr4xxx, and Vr5xxx processors. Mitsubishi (now Renesas) sponsored the support for D10V, D30V, and M32R/D proces- sors. Toshiba sponsored the support for the TX39 Mips processor. Matsushita sponsored the support for the MN10200 and MN10300 processors. Fujitsu sponsored the support for SPARClite and FR30 processors. Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware watchpoints. Michael Snyder added support for tracepoints. Stu Grossman wrote gdbserver. Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made nearly innumerable bug fixes and cleanups throughout gdb. The following people at the Hewlett-Packard Company contributed support for the PA- RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0 (narrow mode), HP’s implementation of kernel threads, HP’s aC++ compiler, and the Text User Interface (nee Terminal User Interface): Ben Krepp, Richard Title, John Bishop, Susan Macchia, Kathy Mann, Satish Pai, India Paul, Steve Rehrauer, and Elena Zannoni. Kim Haase provided HP-specific information in this manual. DJ Delorie ported gdb to MS-DOS, for the DJGPP project. Robert Hoehne made significant contributions to the DJGPP port. Cygnus Solutions has sponsored gdb maintenance and much of its development since 1991. Cygnus engineers who have worked on gdb fulltime include Mark Alexander, Jim 5 Blandy, Per Bothner, Kevin Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler, Fernando Nasser, Geoffrey Noer, Dawn Perchik, Rich Pixley, Zdenek Radouch, Keith Seitz, Stan Shebs, David Taylor, and Elena Zannoni. In addition, Dave Brolley, Ian Carmichael, Steve Chamberlain, Nick Clifton, JT Conklin, Stan Cox, DJ Delorie, Ulrich Drepper, Frank Eigler, Doug Evans, Sean Fagan, David Henkel-Wallace, Richard Henderson, Jeff Holcomb, Jeff Law, Jim Lemke, Tom Lord, Bob Manson, Michael Meissner, Jason Merrill, Catherine Moore, Drew Moseley, Ken Raeburn, Gavin Romig-Koch, Rob Savoye, Jamie Smith, Mike Stump, Ian Taylor, Angela Thomas, Michael Tiemann, Tom Tromey, Ron Unrau, Jim Wilson, and David Zuhn have made contributions both large and small. Andrew Cagney, Fernando Nasser, and Elena Zannoni, while working for Cygnus Solu- tions, implemented the original gdb/mi interface. Jim Blandy added support for preprocessor macros, while working for Red Hat. Andrew Cagney designed gdb’s architecture vector. Many people including Andrew Cagney, Stephane Carrez, Randolph Chung, Nick Duffek, Richard Henderson, Mark Ket- tenis, Grace Sainsbury, Kei Sakamoto, Yoshinori Sato, Michael Snyder, Andreas Schwab, Jason Thorpe, Corinna Vinschen, Ulrich Weigand, and Elena Zannoni, helped with the migration of old architectures to this new framework. Andrew Cagney completely re-designed and re-implemented gdb’s unwinder framework, this consisting of a fresh new design featuring frame IDs, independent frame sniffers, and the sentinel frame. Mark Kettenis implemented the dwarf 2 unwinder, Jeff Johnston the libunwind unwinder, and Andrew Cagney the dummy, sentinel, tramp, and trad unwinders. The architecture-specific changes, each involving a complete rewrite of the architecture’s frame code, were carried out by Jim Blandy, Joel Brobecker, Kevin Buettner, Andrew Cagney, Stephane Carrez, Randolph Chung, Orjan Friberg, Richard Henderson, Daniel Jacobowitz, Jeff Johnston, Mark Kettenis, Theodore A. Roth, Kei Sakamoto, Yoshinori Sato, Michael Snyder, Corinna Vinschen, and Ulrich Weigand. Christian Zankel, Ross Morley, Bob Wilson, and Maxim Grigoriev from Tensilica, Inc. contributed support for Xtensa processors. Others who have worked on the Xtensa port of gdb in the past include Steve Tjiang, John Newlin, and Scott Foehner.
当在使用Docker镜像时,如果出现"value too large for defined data type"的错误,这表示尝试加载或创建的Docker镜像过大,超出了操作系统对文件的大小限制。 造成此错误的原因可能是以下之一: 1. 文件系统限制:操作系统的文件系统可能对于单个文件的大小设置了限制。例如,在某些情况下,ext4文件系统对单个文件的大小限制为16TB。如果Docker镜像的大小超过了此限制,就会出现"value too large for defined data type"的错误。 2. 文件系统类型:某些文件系统类型,如FAT32,对单个文件的大小有限制,通常是4GB。如果使用FAT32格式的分区,尝试加载或创建超过4GB大小的Docker镜像时,就会出现此错误。 要解决此问题,可以考虑以下方法: 1. 更改文件系统限制:可以通过更改操作系统上的文件系统限制来解决此问题。这可能需要对文件系统进行重新格式化或更改文件系统参数。请注意,对文件系统进行更改可能会涉及到风险,因此在执行此操作之前务必备份重要数据。 2. 使用更大容量的文件系统:如果已经使用的文件系统不支持大容量的文件,可以考虑将文件系统更改为支持更大文件的类型,如ext4。 3. 分割镜像:如果没有更改文件系统的选项,可以考虑将Docker镜像分割为更小的部分。这可以通过使用工具来解压和重新打包镜像来实现。当需要使用镜像时,可以按照需要将部分镜像重新组合在一起。 总之,"value too large for defined data type"错误通常是由于Docker镜像的大小超出了文件系统对文件大小的限制所引起的。解决此问题可能需要更改文件系统设置或将镜像分割为更小的部分。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值