zfs list -t snapshot: pointer being freed was not allocated #123
Comments
|
I suggest trying a source-build and see if you get same error. |
|
Didn't fix the problem. |
|
Be interesting to see what gdb or lldb says from either the core, or from running it |
I'm not great with lldb, what should I be doing? |
|
Does it happen if you do zfs list -t all |
|
I do not see this in a test system, however the master branch currently suffers from openzfs/zfs#2094 and the pools I have readily available to it (and of course created by it) all suffer from their ZFS Errata # 1 http://zfsonlinux.org/msg/ZFS-8000-ER/ Is it possible that this affects only pools that do not have the on-disk Errata # 1 incompatibility ? A test would be to create a test pool with whatever build is giving you the bug: $ pwd Alternatively or additionally it would be interesting to know how many numbers are in the "scan =" line returned from $ sudo zdb -U /etc/zfs/zpool.cache.tmp -dddd yourregularpool 1 in partcular whether there are 24 or 25, or whether there is no "scan =" line at all. (You can safely interrupt the zdb process; it can take a long time to complete, but would emit the relevant line within not much more than a few seconds.) There will be 25 for any pool that has been scrubbed, resilvered, or created since the bug was imported into zfs-osx (probably on and since 24 Jan 2014). Other pools should have 24 numbers or no "scan =" line at all. |
|
I'd be surprised if that had anything to do with the price of bread. If it does happen to be related, switching to the branch upstream-20140225 should fix it. |
|
The behaviour seems variable: |
|
Oh in lldb, can you do "bt" which is backtrace. |
|
Here you are. |
Closed
|
I'm having the same problem. My pool (which was created with ZFSOnLinux) has this scan line: This is my lldb: |
|
It is possible this is related to: |
|
Now it happened with 'zfs inherit': |
lundman
added a commit
that referenced
this issue
Mar 11, 2014
|
Could one, or all, of you try e41afca To see if it fixes it, or, what the debug print outputs |
|
A few runs for you... |
|
Well huh, that's not at all as expected. Now we dump the nvlist as well, could you show the output of a failed lsting |
|
No problem: |
|
what happens if you do |
|
stdout: stderr: |
please |
|
|
I wonder if it could be related to one of the properties retrieved but not listed. Perhaps if you run it can trigger it. |
|
Here you go: |
|
Thanks to dch for letting me have access to his broken pool, I have spent a while checking over our userland code. It appears to be all ok. This suggests the problem is in the kernel where we build the nvlists to return. Once interesting thing I noticed was that any combination of props would work; as long as the list did not contain mountpoint. If it had mountpoint, it would frequently core. Since we did do some changes to let our snapshots have mountpoints (due to the way we have to mount them) it could be that we fail to fill in the mountpoint property under some circumstances. |
lundman
added a commit
that referenced
this issue
Apr 3, 2014
causing amusing mayhem. Hopefully addresses issue #123
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Mavericks using the last few nightly builds from lundman's ftp. This is the 20140224 build. Can you give me some pointers on how to debug it?
The text was updated successfully, but these errors were encountered: