This might be caused by a crash and the try of a restart because of this. To trace this, we'd need some kind of a backtrace (gdb) and more information about your configuration. Please try starting icewm using kdm or another login-manager. Does it work that way?

Pavel: Can you reproduce this or is there something known about this issue?

As I wrote, it happens even with the system default configuration.

What may be different from normal situation on my machine is that I'm using twin heads with nvidia (side by side).

icewm segfaults as follows:

(gdb) bt
#0  0x080af7ab in YWindow::create (this=0x80c3bc8) at ywindow.cc:320
#1  0x080af968 in YWindow::handle (this=0x80c3bc8) at ywindow.cc:428
#2  0x08074e7c in YFrameWindow::manage (this=0x818c4e8, client=0x80c3bc8)
    at wmframe.cc:575
#3  0x0807cefb in YFrameWindow::doManage (this=0x818c4e8, clientw=0x80c3bc8)
    at wmframe.cc:341
#4  0x08066542 in YWindowManager::manageClient (this=0x80fe3b0, win=10486035,
    mapClient=true) at wmmgr.cc:1390
#5  0x08066b65 in YWindowManager::mapClient (this=0x80fe3b0, win=10486035)
    at wmmgr.cc:1499
#6  0x08052c9f in TaskBar::showBar (this=0x81576e8, visible=true)
    at wmtaskbar.cc:963
#7  0x0807306e in YWMApp (this=0xbf8ffa0c, argc=0xbf8ffb20, argv=0xbf8ffb24,
    displayName=0x0) at wmapp.cc:1180
#8  0x08073493 in main (argc=Cannot access memory at address 0x0
) at wmapp.cc:1447
#9  0xb79ca738 in __libc_start_main () from /lib/libc.so.6
#10 0x0804cef1 in _start ()

(gdb) list
315             XWindowAttributes attributes;
316
317             XGetWindowAttributes(xapp->display(),
318                                  fHandle,
319                                  &attributes);
320             fX = attributes.x;
321             fY = attributes.y;
322             fWidth = attributes.width;
323             fHeight = attributes.height;
324

(gdb) print attributes
$1 = {x = 10486246, y = -1946389111, width = 0, height = 135848344,
  border_width = 0, depth = -1081083832, visual = 0x80af772, root = 135178424,
  c_class = 1, bit_gravity = 168, win_gravity = 0, backing_store = 0,
  backing_planes = 46, backing_pixel = 0, save_under = 8, colormap = 0,
  map_installed = 0, map_state = 2048, all_event_masks = -1081083904,
  your_event_mask = 2048, do_not_propagate_mask = 46, override_redirect = 15,
  screen = 0x80c149a}

(gdb) print *this
warning: can't find linker symbol for virtual table for `YWindow' value
warning:   found `TaskBar::~TaskBar()' instead
$1 = {_vptr.YWindow = 0x80544f0, fParentWindow = 0x8053e50,
  fNextWindow = 0x80b0b10, fPrevWindow = 0x80b0ae0, fFirstWindow = 0x8051850,
  fLastWindow = 0x80530b0, fFocusedWindow = 0x804d920, fHandle = 134940544,
  flags = 134948864, fStyle = 134948800, fX = 134940368, fY = 134552272,
  fWidth = 134552080, fHeight = 134946176, fPointer = {fCursor = 134551776,
    fOwned = 32}, unmapCount = 134602384, fGraphics = 0x804d950,
  fEventMask = 134614480, fWinGravity = 134933504, fBitGravity = 134933520,
  fEnabled = 32, fToplevel = 236, fDoubleBuffer = 10, accel = 0x805f950,
  fToolTip = 0x805de00, static fClickEvent = {type = 0, serial = 0,
    send_event = 0, display = 0x0, window = 0, root = 0, subwindow = 0,
    time = 0, x = 0, y = 0, x_root = 0, y_root = 0, state = 0, button = 0,
    same_screen = 0}, static fClickWindow = 0x0, static fClickTime = 0,
  static fClickCount = 0, static fClickDrag = 0, static fClickButton = 0,
  static fClickButtonDown = 0, static fToolTipTimer = 0x0, fDND = 96,
  XdndDragSource = 134933216, XdndDropTarget = 134535536,
  static fAutoScroll = 0x0}

The same segfaults without twin view (using nv driver instead of nvidia), with the system default configurations.

Starting from KDM results in the same.  icewm-session tries to icewm repeatedly.
The problem is the crash of icewm itself.

I will look at it know. I have also some bug report from icewm maintainer. 
Could be same problem.

I reproduce that icewm do not start. Could you please post here output from:
startx icewm -- :2

icewm doesn't show any relevant messages but just segefaults.

The strict-aliasing patch is pretty broken.
The fixed one is below.

Created attachment 64314 [details]
Fixed patch for strict-aliasing fix

The fixed package is submitted to STABLE.

*** Bug 145765 has been marked as a duplicate of this bug. ***