Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Rafeinator

DB2 Testing Segmentation Violations

Recommended Posts

It's been a couple of months since I last posted, but I'm in need of assistance once again.

I am using the most recent version of DB2, and am using my old copy of Doomsday 1.8.6 to test maps, because when I try to use 1.9.7 it's really laggy and takes forever to load. I am also using a different computer.

The new problem I am having is that any WAD I try to test (Ultimate DOOM, DOOM II, Plutonia/TNT, The Master Levels, Maximum DOOM, my own custom WADs) all quit right after starting up with a "segmentation violation".

After every test, doomsday.out will contain a message like this:
"W_AddFile: ERROR: T:\Temp\Administrator\byf4bau4\9is0mc2h.wad not found!"

All the more puzzling is that I've made one small test WAD since moving to this new machine that will sometimes actually work, but when I exit back out to DB2 and load a different WAD that gives me a segment violation, if I go back to this test WAD, it will then give me a segmentation violation error too.

I know that segmentation violations can be caused by hundreds of different issues and that this is an open-ended problem, but I would appreciate any tips on where to start looking to fix this problem.

Share this post


Link to post

A segmentation violation occurs when a program access an area of memory that the program is not permitted to access.

To actually see what is causing the segmentation violation, you'd have to debug the program and run it until it crashes. Then once you are debugging, you can only then see the true cause of the crash.

Share this post


Link to post
Rafeinator said:

and am using my old copy of Doomsday 1.8.6 to test maps, because when I try to use 1.9.7 it's really laggy and takes forever to load. I am also using a different computer.

Have you tried a clean reinstall? (Don't know how to do it w/1.8.6, though). Also, try unstable 1.9.8 builds. They only take half of forever to load! :)

Share this post


Link to post

Segmentation faults do not give the program time to leave error messages like that. But trying to load a wad, failing, then referencing the wad anyway, can cause a segfault.
Is that an actual filename of yours or something that the program came up on its own ??
The first question is where that name comes from and why is it not found.
Check config files, history files, for the wad file name.
Sounds like you just copied your working directory over to another computer and now have dangling file references.
Try to create a dummy wad (empty file) of that name and see if it stops the segfaults, as a test.

Many editors require a copy of one of the id wads to be present and an old soft link to satisfy that need has caused problems for me in the past.

Share this post


Link to post
GhostlyDeath said:

A segmentation violation occurs when a program access an area of memory that the program is not permitted to access.

To actually see what is causing the segmentation violation, you'd have to debug the program and run it until it crashes. Then once you are debugging, you can only then see the true cause of the crash.

Share this post


Link to post
wesleyjohnson said:

Is that an actual filename of yours or something that the program came up on its own ?

Doom Builder 2 saves the map in a temporary file when testing, so yes a name like "9is0mc2h.wad" is perfectly normal.

Share this post


Link to post

Thanks for the tips guys.
I haven't had much time to mess around with it the past day or so, but I did try uninstalling 1.8.6 (well, kind of just deleting) from my G drive, and reinstalling it in my C drive.
It didn't fix the problem, but doomsday gave me a different error when I tried to run it, something about a buffer overrun error, and having to terminate the program.
I looked it up, and I think what's happening is doomsday is creating a temporary WAD in my temp drive, and when it comes back to the file, Window's data execution prevention (DEP) program is terminating doomsday before it creates a buffer overrun.
At least, that's my theory from reading the wikipedia article. If this is helpful in solving the problem, let me know.

Share this post


Link to post

Dday 1.8.6 (I haven't checked wheter 1.9.7 removes the limit) only supports folder pathes of less than 256 characters.

Share this post


Link to post

I've completely given up hope of solving this on my own, so I'll just post the entire Doomsday.out file from testing "entryway" from the Doom 2 IWAD.

-

Con_Init: Initializing the console.
SW_Init: Startup message window opened.
Executable: Version 1.8.6 Jan 8 2005 (DGL).
Memory zone: 32.0 Mb.
Parsing configuration files.
W_Init: Init WADfiles.
W_AddFile: G:\Depths of DOOM\DOOM WAD Collection\DOOM2.WAD
IWAD identification: 00f36acb
W_AddFile: Data\Doomsday.wad
W_AddFile: Data\jDoom\jDoom.wad
IWAD identification: 00056533
W_AddFile: ERROR: T:\Tmp\ibu2nnq6\o33ntohd.wad not found!
Parsing user.cfg.
Reading definition file: Defs\Doomsday.ded
Reading definition file: Defs\jDoom\jDoom.ded
138 sprite names
974 states
140 things
8 lights
112 sound effects
68 songs
335 text strings
27 particle generators
22 animation groups
49 surface decorations
69 map infos
12 finales
Sys_Init: Setting up machine state.
Sys_Init: Initializing keyboard, mouse and joystick.
Sys_InitTimer.
Sys_InitMixer: NVIDIA(R) nForce(TM) Audio
Sfx_Init: Initializing DirectSound...
DS_DSoundInit: EAX initialized.
DM_WinMusInit: 2 MIDI-Out devices present.
DM_WinMusInit: MIDI initialized.
S_Init: OK.
R_Init: Init the refresh daemon.
R_InitModels: Initializing MD2 models.
R_InitModels: Done in 0.00 seconds.
Net_InitGame: Initializing game data.
GL_Init: Initializing Doomsday Graphics Library.
DG_Init: OpenGL.
OpenGL information:
Vendor: ATI Technologies Inc.
Renderer: Radeon X1650 Series
Version: 2.1.8545 Release
Extensions:
GL_AMD_performance_monitor GL_ARB_depth_texture
GL_ARB_draw_buffers GL_ARB_fragment_program
GL_ARB_fragment_program_shadow GL_ARB_fragment_shader
GL_ARB_framebuffer_object GL_ARB_half_float_pixel
GL_ARB_half_float_vertex GL_ARB_map_buffer_range
GL_ARB_multisample GL_ARB_multitexture
GL_ARB_occlusion_query GL_ARB_pixel_buffer_object
GL_ARB_point_parameters GL_ARB_point_sprite
GL_ARB_shader_objects GL_ARB_shader_texture_lod
GL_ARB_shading_language_100 GL_ARB_shadow
GL_ARB_shadow_ambient GL_ARB_texture_border_clamp
GL_ARB_texture_compression GL_ARB_texture_cube_map
GL_ARB_texture_env_add GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3
GL_ARB_texture_float GL_ARB_texture_mirrored_repeat
GL_ARB_texture_non_power_of_tw GL_ARB_texture_rectangle
GL_ARB_transpose_matrix GL_ARB_vertex_array_object
GL_ARB_vertex_buffer_object GL_ARB_vertex_program
GL_ARB_vertex_shader GL_ARB_window_pos
GL_ATI_draw_buffers GL_ATI_envmap_bumpmap
GL_ATI_fragment_shader GL_ATI_meminfo
GL_ATI_separate_stencil GL_ATI_texture_compression_3dc
GL_ATI_texture_env_combine3 GL_ATI_texture_float
GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_equation_separate
GL_EXT_blend_func_separate GL_EXT_blend_minmax
GL_EXT_blend_subtract GL_EXT_compiled_vertex_array
GL_EXT_copy_texture GL_EXT_draw_range_elements
GL_EXT_fog_coord GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object
GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays
GL_EXT_packed_depth_stencil GL_EXT_packed_pixels
GL_EXT_point_parameters GL_EXT_rescale_normal
GL_EXT_secondary_color GL_EXT_separate_specular_color
GL_EXT_shadow_funcs GL_EXT_stencil_wrap
GL_EXT_subtexture GL_EXT_texgen_reflection
GL_EXT_texture3D GL_EXT_texture_compression_s3t
GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotro
GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp
GL_EXT_texture_object GL_EXT_texture_rectangle
GL_EXT_texture_sRGB GL_EXT_texture_swizzle
GL_EXT_vertex_array GL_KTX_buffer_region
GL_NV_blend_square GL_NV_texgen_reflection
GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod GL_WIN_swap_hint
WGL_EXT_swap_control
GLU Version: 1.2.2.0 Microsoft Corporation
Texture units: 2
Maximum texture size: 4096
Maximum anisotropy: 16
Multitexturing enabled (full).
Con_StartupInit: Init startup screen.
jDoom Version 1.15.6 Jan 8 2005 (Doomsday)
----------------------------------------------------------------------
DOOM 2: Hell on Earth
----------------------------------------------------------------------
P_Init: Init Playloop state.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.
M_Init: Init miscellaneous info.
SetupLevel: map01
Opened PWAD file : bspcache\doom2\DOOM2-2B54\MAP01.wad
Reading 11 dir entries at 0xAFFC

Creating nodes using tunable factor of 7


Building GL nodes on MAP01

Loaded 383 vertices, 59 sectors, 529 sides, 370 lines
Map goes from (-1304,-960) to (2072,2688)
Creating Segs...
Built 203 NODES, 204 SSECTORS, 1058 SEGS, 515 VERTEXES
Heights of left and right subtrees = (14,12)

Saving WAD as bspcache\doom2\DOOM2-2B54\MAP01.gwa

Total serious warnings: 0
Total minor warnings: 0
(GL data found)
GL_VERT v2.0
Segmentation Violation

-

If anyone sees something in there that could solve my problem, PLEASE let me know. I'm exasperated.

Update: I had thought that the missing temp WAD was related to the segfault problem, but it isn't. When I play jdoom.exe regularly (not as the testing engine for db2) and start a new game it still gives me a segfault without the missing WAD error.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×