Did 36.3 kill loading?

  • Saza
    20th Jul 2010 Member 0 Permalink
    Every time I go to load something from the online, Powder crashes/freezes/stops responding, whatever you want to call it.

    Is this me, and is there a fix?
  • Simon
    20th Jul 2010 Administrator 0 Permalink
    A couple of people have experienced this, I would first suggest deleting powder.def and trying again.
    I can't debug this as I haven't managed to repeat it myself.
  • Saza
    20th Jul 2010 Member 0 Permalink
    Deleting powder.def worked, thanks!
  • plypencil
    20th Jul 2010 Member 0 Permalink
    I take it MoFo was being naughty? I dont know how the updater works but could you not tell it to remove the file on update?
  • Simon
    20th Jul 2010 Administrator 0 Permalink
    I'm doing that with the next update, but the problem is that it requires the file to be there to update, which will mean users will be presented with an "update failed" warning
    Also, MoFo is being changed to PDef
  • plypencil
    20th Jul 2010 Member 0 Permalink
    The reason for the change being?

    And create a new file once the current one is deleted :). Also is there anyway I can assist you? I can't compile the code (Unless I use it on linux) but I am able to edit.
  • Simon
    20th Jul 2010 Administrator 0 Permalink
    The reason for the change is to make the program deem the current powder.def file as invalid and delete it.
  • ayanami
    20th Jul 2010 Member 0 Permalink
    I have this problem with 64 bit version of powder on Linux. It crashes when powder runs with scale:2. 32 bit version works OK with old powder.def file (with scale:2). All versions are manually compiled.
    I can assist you with backtrace, which was printed by glibc.
  • plypencil
    20th Jul 2010 Member 0 Permalink
    If you can provide any logs to me I may be able to find your problem. Sounds like an invalid type conversion causing it to crash seeing as the only difference is an integer being changed.

    EDIT:
    Does both 32 and 64 bit work fine in scale:1 mode?
  • ayanami
    20th Jul 2010 Member 0 Permalink
    Yes. Both 32 and 64 bit versions works fine in scale:1 mode.
    Backtrace from 64 bit version:

    *** glibc detected *** ./powder: free(): invalid next size (fast): 0x000000000265c050 ***
    ======= Backtrace: =========
    /lib64/libc.so.6[0x7fa016ac0156]
    /lib64/libc.so.6(cfree+0x6c)[0x7fa016ac4a9c]
    ./powder[0x431f2f]
    ./powder[0x431fe0]
    ./powder[0x428647]
    ./powder[0x42d425]
    /lib64/libc.so.6(__libc_start_main+0xfd)[0x7fa016a6d9ed]

    (I can send memory map only to admins :o)

    EDIT: Most errors in free(). Rarely, this happens sometimes:
    *** glibc detected *** ./powder: realloc(): invalid next size: 0x0000000002198650 ***
    ======= Backtrace: =========
    /lib64/libc.so.6[0x7f6b6788c156]
    /lib64/libc.so.6[0x7f6b67891864]
    /lib64/libc.so.6(realloc+0xf0)[0x7f6b67891bc0]
    ./powder[0x432d74]
    ./powder[0x42876c]
    ./powder[0x42d425]
    /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f6b678399ed]
    ./powder[0x401af9]

    Maybe this will be helpful.