Bugzilla – Full Text Bug Listing
| Summary: | A variable with a very long value triggers "Could not determine GDB version..." error | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Sergey Prigogin <eclipse.sprigogin> |
| Component: | cdt-debug-dsf-gdb | Assignee: | Sergey Prigogin <eclipse.sprigogin> |
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> |
| Severity: | normal | ||
| Priority: | P3 | CC: | cdtdoug, nobody, pawel.1.piech |
| Version: | 8.2 | ||
| Target Milestone: | 8.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Sergey Prigogin
A proposed fix is in Gerrit at https://git.eclipse.org/r/#/c/12991/. How in the world did you find this out? For the knowledge base, which shell are you using? What output does GDB return when this happens, is it something like "Argument list too long"? I think it is a rare enough case that we can put it in. I suggest logging when such a variable is skipped, so that the user can at least find out why it is ignored. I'll put the comment in Gerrit. Looking a bit on Google :), it is not clear that the 512K is a hard limit. It may be system-dependent. That would mean that on some other systems, this fix would not help. Could you explain a bit more how to reproduce this? (In reply to comment #2) > How in the world did you find this out? One of our users had a mixed C++/Java project where project_classpath variable was almost 1MB in size. > For the knowledge base, which shell are you using? bash > What output does GDB return when this happens, > is it something like "Argument list too long"? The return code was 127, which means "command not found". It's a mystery why, but a Google search for "argument list too long return code 127" does turn up some results. > I think it is a rare enough case that we can put it in. > > I suggest logging when such a variable is skipped, so that the user can at > least find out why it is ignored. I'll put the comment in Gerrit. I have doubts on usefulness of such logging. Users may be confused by the logged messages since they have no idea where the launch environment variables are coming from. How about logging a warning if the variable name is not project_classpath, or just filtering out project_classpath unconditionally, irrespective of its value? The root cause of the problem seems to lie in nondiscriminatory nature of the algorithm for collecting variables to be included in the launch environment. (In reply to comment #3) > Looking a bit on Google :), it is not clear that the 512K is a hard limit. > It may be system-dependent. That would mean that on some other systems, > this fix would not help. Indeed, the limit is most likely system dependent, but I could not find any reference to it on the Web. I've determined the value experimentally, getconf ARG_MAX returns 2097152 which is 4 times larger. > Could you explain a bit more how to reproduce this? One way to reproduce this is to create a project with C++ and Java natures and set classpath to a very long string. Another option is to filter out all EclipseVarMacro variables since they have nothing to do with environment variables. In my test it dropped the following variables: target.arch = x86 selected_resource_name = Mixed cdt_pathentry_var = null dsfPerlExecutable = /usr/bin/perl config_description = null tmpdir_name = /tmp/1369349914576-0 system = null build_files = null java_type_name = null selected_resource_loc = /home/sprigogin/workspaces/debug_cdt/Mixed git_work_tree = git_repo_relative_path = system_path = null env_var = null build_type = none config_name = null git_branch = selected_resource_path = /Mixed eclipse_home = /opt/eclipse3.8/ target.nl = en_US location_contents = target.ws = gtk workspace_loc = /home/sprigogin/workspaces/debug_cdt git_dir = build_project = null java_extensions_regex = \.java: system_property = null project_classpath = /home/sprigogin/workspaces/debug_cdt/Mixed/bin ee_home = null target_home = /opt/eclipse3.8 target.os = linux *** cdt git genie on behalf of Sergey Prigogin ***
Bug 408522. Don't include EclipseVarMacro variables when creating launch
environment variables. EclipseVarMacro variables are internal to Eclipse
and have nothing to do with environment variables.
Change-Id: I588eaf8db6edc1974dca53e7aba9870d01fa9438
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=55afbf6bc5b522194a7474da2b1c90f5828ffd4a
(In reply to comment #6) Oops. I didn't mean to push this commit. I'll revert it if there are objections to it. (In reply to comment #7) > (In reply to comment #6) > > Oops. I didn't mean to push this commit. I'll revert it if there are > objections to it. You're too used to pressing that "Commit and Push" button :) I'll have a look and let you know my opinion. (In reply to comment #5) > Another option is to filter out all EclipseVarMacro variables since they > have nothing to do with environment variables. So, from what I can see, in Preferences -> Run/Debug -> String Substitutions users can define variables which will be included in the EclipseVarMacro list. Such variables are currently passed to GDB and appear in its environment, and are passed down to the program being debugged. This provides the user with a way to define variables that will always be passed to GDB. So the proposed change is non-backwards compatible. Note that there is another way to pass variables to GDB which is through the launch 'Environment' tab. The problem is that such variables have to be manually re-created for any new launch configuration. I think we have to revert that commit. Any other ideas? If we have no better alternative, I find the original solution, although not quite right, to have much less impact. (In reply to comment #9) Would it be better to filter out project_classpath specifically? A patch that skips project_classpath variable is uploaded to https://git.eclipse.org/r/#/c/13147/1. This is the most conservative change although not the most elegant. (In reply to comment #11) > A patch that skips project_classpath variable is uploaded to > https://git.eclipse.org/r/#/c/13147/1. This is the most conservative change > although not the most elegant. Agreed. Such a change should have no negative impacts, while fixing the problem. |