Error: Unpack requires a string argument of length 4

Bug #908856 reported by Eric on 2011-12-26
This bug affects 8 people
Affects Status Importance Assigned to Milestone
disper (Ubuntu)

Bug Description

I'm using disper 0.3.0 on Arch linux.

Disper successfully change my display settings the first time i run it, then every other time i try to execute it (even with "-p") it fails with this error:
"Unpack requires a string argument of length 4"

I've an Nvidia 9300M GS on a laptop and use disper to extend display to an external monitor, when available.
I'm using Nvidia drivers 290.10.

This is the full output when i run "disper -p -v":

$ disper -p -v
Enabled plugins:
could not get scaling for screen CRT-0, reverting to "default"
unpack requires a string argument of length 4

Eric (eric-pub) wrote :
wvengen (wvengen) wrote :

Hi, thanks for your bug report. This is something that shouldn't happen! Could you run the following command? I think it should give the same error, please report the full backtrace.
  PYTHONPATH=/usr/share/disper/src python -c 'import nvidia; n=nvidia.NVidiaControl(); print n.probe_displays(nvidia.Screen(0))'

Eric (eric-pub) wrote :

It runs successfully (no error given).
It simply output:
['CRT-0', 'DFP-0']

Note: i should use "python2" instead of "python"... running python executes the v3 version that gives syntax errors in script.

So i've run this:
PYTHONPATH=/usr/share/disper/src python2 -c 'import nvidia; n=nvidia.NVidiaControl(); print n.probe_displays(nvidia.Screen(0))'

Ondřej Vodáček (voda) wrote :

Hi , I have the same problem on a Quadro FX 880M card with nvidia 290.10 drivers.
The command you posted runs fine and outputs: ['DFP-0', 'DFP-1']
Running on Debian testing.

Josh (2012-t) wrote :

My error is similar, but slightly different:

unpack requires a string argument of length 16148

I am using a MBP 5,3, with external Apple Cinemedia Monitor, Ubuntu 11.10 with unity.

Output of the requested command:

$ PYTHONPATH=/usr/share/disper/src python -c 'import nvidia; n=nvidia.NVidiaControl(); print n.probe_displays(nvidia.Screen(0))'
['DFP-0', 'DFP-2']

Let me know if I can assist further with this bug. My symptom is NOT consistent. I can run the 'disper -e' command a dozen times, and sometimes this will happen 11 times, and others not at all. I simply run the command over and over when I connect the monitor.

Jeff Levin (jeff-h670z) wrote :

I'm having the same issues with a Thinkpad t420s and Nvidia 4200 with optimus chip. I have optimus disabled and gpu set to discreete.

$ disper -s -v

Enabled plugins:
using specified displays: DFP-0
resolutions of DFP-0: 320x175, 320x200, 360x200, 320x240, 400x300, 416x312, 512x384, 640x350, 576x432, 640x400, 680x384, 720x400, 640x480, 720x450, 640x512, 700x525, 800x512, 840x525, 800x600, 960x540, 832x624, 960x600, 896x672, 928x696, 1024x768, 1152x864, 1360x768, 1440x900, 1600x900
unpack requires a string argument of length 4

PYTHONPATH=/usr/share/disper/src python -c 'import nvidia; n=nvidia.NVidiaControl(); print n.probe_displays(nvidia.Screen(0))'

['DFP-0', 'DFP-3', 'DFP-5']

Not sure if the below helps. I hit the same issue using a Quadro FX 880M (NVIDIA Driver Version:295.20, NV-CONTROL Version:1.27) when in a docking station with 2 monitors connected via DVI (and the builtin laptop monitor off). Using disper 0.3.0.

I ran disper through the python debugger (though I'm no python programmer so if there is something else that would help let me know) and got a stack trace from the error:

-> exec cmd in globals, locals
-> main()
-> disper.switch()
-> print self.export_config()
> /usr/share/disper/src/
-> return self.switcher.export_config()
-> self.nv.get_xinerama_info_order(self.screen).split(',')))
-> res = self.query_string_attribute(target, [], NV_CTRL_STRING_TWINVIEW_XINERAMA_INFO_ORDER)
-> return _NVCtrlQueryStringAttributeReply(binrp)
-> minx.XData('STRING8',self.n,'string'))
-> rdict[arg.value] = struct.unpack( structcode, data[:sz] )[0]

Then printed the value of some variables in the local area:

(Pdb) pp data[:sz]
(Pdb) pp structcode

(Pdb) pp ad
(Pdb) pp self.n

disper -p only prints:

could not get scaling for screen DFP-0, reverting to "default"
unpack requires a string argument of length 4

for me (DFP-0 is the disabled internal monitor).

Josh (2012-t) wrote :

Added strace

Martin Henze (martin-henze) wrote :

Same issue on Ubuntu 12.04 Beta 2 with disper 0.3.0-1 and a GeForce 320M on a MacBook Pro.

I'm using autorandr/autodisper to control disper. The first switch worked fine, after that the problem occured.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in disper (Ubuntu):
status: New → Confirmed
wvengen (wvengen) wrote :

Thanks everyone for adding your debug information! It seems to be a fairly hard problem. I'll try to look into it when I have the time. Please feel free to add more debugging info when you think it would be useful.

Martin Henze (martin-henze) wrote :

After reading a bit about what unpack is doing: At least I'm running on 64 bit. If this holds for the others as well, this might help in figuring out what's going on.

Mike Cook (mikewillcook) wrote :

Same problem on F16 (x86_64) with Thinkpad W520 (set to discrete, using 2 external and internal off)...

After playing around a bit I found in my case decode (in is getting down to the unpack call with "s0I" format and 4 null bytes of data, but the sz is being set to 1. So, the unpack fails since it's only getting 1 byte worth of data (data[:sz]) when it needs 4.

So, for a q

Mike Cook (mikewillcook) wrote :

Er, so, for a quick workaround I stuck a sanity check to reset sz to the necessary format size if it was too low, and then things seem to consistently work for me (sorry, not a python guy)...

--- /usr/share/disper/src/nvidia/ 2012-01-17 14:13:47.000000000 -0700
+++ /usr/share/disper/src/nvidia/ 2012-04-26 17:27:43.909106422 -0600
@@ -124,6 +124,8 @@
             asz = rdict[arg.size]

         sz = asz * fsz
+ if sz < struct.calcsize(structcode):
+ sz = struct.calcsize(structcode)

         if asz == 1:
             rdict[arg.value] = struct.unpack( structcode, data[:sz] )[0]

Mike Cook (mikewillcook) wrote :

Now, that's not a proper solution (should check the data length is long enough), but hopefully it helps identify the issue of why sz isn't getting set properly. (And sorry for the comment spam, as edit would be nice.)

Dave Lauer (dlauer) wrote :

FWIW, I had the exact same problem and your python edit has fixed it. I'm on a Lenovo Thinkpad W520 with an Nvidia Quadro 1000M in Discrete Mode.

Ilya Kolpakov (ilya-kolpakov) wrote :

Had the same problem on my Dell laptop with Quadro NVS 160M running Ubuntu 12.04. The workaround in #14 fixed the problem so now I can switch between profiles.

ed thompson (eddy-crim) wrote :

Just a me-too on this

 - NVIDIA Corporation GT218 [NVS 3100M]
 - Thinkpad T510
 - Driver 295.40
 - Ubuntu 12.04 64-bit

Ted (buffalobillion) wrote :

I've got the same problem, and I'm willing to try the workaround in #14. Okay, stupid question: I've made the changes in the What do I do next? How do I compile it?

wvengen (wvengen) wrote :

Thanks, Mike, for getting to the cause of the problem! This might be a bug in X (especially if a protocol detail differs between i386 and x86_64), but at least we can workaround it. I'll look into this in more detail later.

Changed in disper:
importance: Undecided → High
milestone: none → 0.3.1
status: New → Triaged
Phil (phil-vr7kfh) wrote :

just another me 2...

Inspiron E6400
Nvidia Quadro NVS 160M
Driver Version 295.40

After rebooting switching profiles works fine - however auto-disper seems to be always get broken (showing the stated error message) after the system resumes from standby.

Roger Preece (rwpreece) wrote :

I used the python fix from Mike Cook in comment #14. It works fine now.

I'm wondering if it's related to some python updates that I've received within the last couple of weeks. I'm on Linux Mint 13 KDE which is based on Ubuntu 12.04 (if I remember correctly).

wvengen (wvengen) wrote :

Is this still an issue? Could you please verify that it is an issue with 0.3.0, and if the current disper bzr trunk solves it? I've committed the workaround as mentioned in comment #14.

Changed in disper:
assignee: nobody → wvengen (wvengen)
status: Triaged → Fix Committed
Mike Cook (mikewillcook) wrote :

I've since updated from F16 to F18 (and all the kernel/driver updates that entails) on the same hardware, and it appears the problem no longer occurs for me. I verified it works with or without the workaround in place.

wvengen (wvengen) wrote :

Thanks, Mike, for checking!

wvengen (wvengen) on 2013-04-23
Changed in disper:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers